Instead of going through a runtime function for keyed loads
on strings we invoke a separate specialized stub that
assumes string as receiver type and the key to be a number.
The stub calls a JS builtin function to return the corresponding one-character string.
Review URL: http://codereview.chromium.org/521041
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3556 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a stub to allocate and fill a string object with a substring from another string.
Use the rep movs instruction to copy the string data as it turned out to be the fastest way.
While preparing this I experimented with some SSE2 instructions, so the instructions movdqa and movdqu are still in the IA-32 assembler even though they are not used.
Review URL: http://codereview.chromium.org/525085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3554 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When generating code for object and array literals we performed
the check if the a boilerplate already exists in generated code.
In the top-level compiler we now do this check in a new runtime
function. This makes the generated code more compact for top-level code.
Review URL: http://codereview.chromium.org/465148
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3437 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds a code stub which can do most of what Heap::AllocateConsString can do. It bails out if the result cannot fit in new space or if the result is a short (flat) string and one argument is an ascii string and the other a two byte string. It also bails out if adding two one character strings as Heap::AllocateConsString has special handling of this utilizing the symbol table. The stub is used both for the binary add operation and for StringAdd calls from runtime JavaScript files. Extended the string add test to cover all sizes of flat result stings.
Review URL: http://codereview.chromium.org/442024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3400 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The different length string types was used to encode the string length and the hash in one field. This is now split into two fields one for length and one for hash. The hash field still encodes the array index of the string if it has one. If an array index is encoded in the hash field the string length is added to the top bits of the hash field to avoid a hash value of zero.
On 32-bit this causes an additional 4 bytes to be used for all string objects. On 64-bit this will be half on average dur to pointer alignment.
Review URL: http://codereview.chromium.org/436001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
potentially leading to bogus FatalProcessOutOfMemory situations. Also
fixed a few cases where callers relied on getting a NewSpace object
back (to avoid write barrier overhead) which they can't when
always_allocate is in effect.
Review URL: http://codereview.chromium.org/391018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3285 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
String slices from RegExp replace results is now encoded in either one or two smis. Substrings are not used any more.
If the existing one smi encoding cannot hold the start/length information two smis are used the first having the negative length and the second having the start.
This is in preparation for removing string slices.
Review URL: http://codereview.chromium.org/342015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3153 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of individual changes:
- Added infrastructure for custom stub caching.
- Push the code object onto the stack in exit calls instead of a
debug/non-debug marker.
- Remove the DEBUG_EXIT frame type.
- Add a new exit stub generator for API getters.
Review URL: http://codereview.chromium.org/330017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3130 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. This is a follow-on CL to
http://codereview.chromium.org/293023 .
Based on review feedback, defined the behavior of storing NaN and
+/-Infinity into external arrays of integer types as storing 0. Added
test cases. Added fucomi instruction to assembler. Fixed bug in
KeyedLoadIC::GenerateExternalArray when allocation of HeapNumber
failed. Fixed bug in encoding of 16-bit immediate arithmetic
instructions in 64-bit port.
Removed raising of exceptions for negative array indices passed to
external arrays and associated tests. Based on current discussion in
WebGL working group, will probably end up removing the exception
throwing altogether.
Review URL: http://codereview.chromium.org/294022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
currently compiled the same as with the optimizing compiler: they are
cloned from a boilerplate object and the boilerplate objects are
lazily constructed.
Also changed argument pushing on ARM to use stm (store multiple),
which required changing the order of arguments to the runtime
functions DeclareGlobals and NewClosure. They were only used from
generated code.
Finally, changed the toplevel code generator so that stack pops to
discard a temporary became addition to the stack pointer on ia32 and
x64.
Review URL: http://codereview.chromium.org/303021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3110 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. The optimizations are patterned after
those previously done for CanvasPixelArray. This CL adds all of the
necessary framework but continues to use the generic KeyedLoadIC and
KeyedStoreIC code, to create a baseline for benchmarking purposes. The
next CL will add the optimized ICs to ic-ia32.cc and ic-x64.cc.
These new CanvasArray types have different semantics than
CanvasPixelArray; out-of-range values are clamped via C cast
semantics, which is cheaper than the clamping behavior specified by
CanvasPixelArray. Out-of-range indices raise exceptions instead of
being silently ignored.
As part of this work, pulled FloatingPointHelper::AllocateHeapNumber
up to MacroAssembler on ia32 and x64 platforms. Slightly refactored
KeyedLoadIC and KeyedStoreIC. Fixed encoding for fistp_d on x64 and
added a few more instructions that are needed for the new ICs. The
test cases in test-api.cc have been verified by hand to exercise all
of the generated code paths in the forthcoming specialized ICs.
Review URL: http://codereview.chromium.org/293023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
"jsregexp.h" and "jump-target.h" required "macro-assembler.h" to
always be included first. Instead the include of "macro-assembler.h"
has moved into those header files.
"dateparser-inl.h" required "dateparser.h" to always be included
first. Instead the include of "dateparser.h" has moved into
"dateparser-inl.h".
Review URL: http://codereview.chromium.org/267117
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Based on a recent patch for Webkit.
trim is defined in ES 5 section 15.5.4.20.
Author: Jan de Mooij <jandemooij@gmail.com>
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the Runtime_DebugGetPropertyDetails the raw object pointers from a LookupResult could be used after a GC might have happened. Fixed the bug and restructured the code to make it less likely for changes to the code to re-introduce the bug.
Skipped a long running test from the ARM simulator in debug mode (and renamed the test).
Review URL: http://codereview.chromium.org/204039
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The algorithm for finding the inner-most function containing a script break point was not correct when the script only contained one function. In that case the script function and not the actual function in the script could be returned depending on the order of the objects in the heap.
TEST=cctest/test-debug/ScriptBreakPointReload
BUG=none
Review URL: http://codereview.chromium.org/193059
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2862 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Removed a false assertion in ScopeIterator that assumed context extension to never be a JSContextExtensionObject.
The context extension object in a 'with' context is JSContextExtensionObject iff the 'with' statement is generated from a catch block in order to extend its local scope with a variable holding exception object. This is how we differentiate 'catch' scope from 'with' scope.
Chrome bug:
http://code.google.com/p/chromium/issues/detail?id=17229
Review URL: http://codereview.chromium.org/202005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2843 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a
specialized constructor stub is now generated. This generated code allocates the
object and fills in the initial properties directly. If this fails for some
reason code continues in the generic constructor stub which in turn might pass
control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change.
For x64 and ARM the generic construct stub is used.
This is change is identical to http://codereview.chromium.org/174392 (committed in r2753 and reverted in r2754) except that a few parts have already been committed from http://codereview.chromium.org/173469 (committed in r2762).
Review URL: http://codereview.chromium.org/173470
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When copying a map always set the descriptor array to describe the pre-allocated properties, even when descriptors are to be dropped.
Added a test which otherwise failed with an assert on ARM in debug mode. The reason for it only surfasing on ARM is that the NewObject runtime function is always used for allocating new JSObjects on ARM.
This change includes a few parts of http://codereview.chromium.org/174392 needed to trigger the error.
Review URL: http://codereview.chromium.org/173469
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2762 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a specialized constructor stub is now generated. This generated code allocates the object and fills in the initial properties directly. If this fails for some reason code continues in the generic constructor stub which in turn might pass control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change. For x64 and ARM the generic construct stub is used.
Review URL: http://codereview.chromium.org/174392
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During parsing functions are analyzed for statements of the form this.x = ...;. These assignments are categorized in two types: simple and non simple. The simple ones are where the right hand side is known to be either a constant or an argument to the function. If a function only contains statements of this type the property names are collected and for the simple assignments the index of the argument or the constant value assigned are stored as well.
When the initial map for a function is created and the function consists of only this type of assignemnts the initial map is created with a descriptor array describing these properties which will be known to always exist in an object created from the function.
The information on this property assignments is not collected during pre-parsing so if compiling using pre-parse data these optimization hints are not available.
Next step will be to use the information collected for the simple assignments to generate constructor code which will create and initialize the object from this information without calling the code for the function.
Review URL: http://codereview.chromium.org/172088
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2710 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allocate the code stubs dictionary and non monomorphic cache dictionary with an initial size which avoids these dictionaries to be expanded during bootstrapping. This gets rid of 9 dictionary expansions during bootstrapping.
Preallocate the dictionary when normalizing an object to a size sufficient for holding the number of properties which is expected to be added to the object. This is used when ceating an object from an object literal boilerplate where multiple properties are known to be added. This gets rid of 10 dictionary expansions during bootstrapping.
There are now 3 dictionary expansions left during bootstrapping.
Review URL: http://codereview.chromium.org/160382
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Error, ReferenceError, etc. are given a stack property that gives a
stack trace. Here's an example stack trace:
ReferenceError: FAIL is not defined
at Constraint.execute (deltablue.js:527)
at Constraint.recalculate (deltablue.js:426)
at Planner.addPropagate (deltablue.js:703)
at Constraint.satisfy (deltablue.js:186)
at Planner.incrementalAdd (deltablue.js:593)
at Constraint.addConstraint (deltablue.js:164)
at Constraint.BinaryConstraint (deltablue.js:348)
at Constraint.EqualityConstraint (deltablue.js:517)
at chainTest (deltablue.js:809)
at deltaBlue (deltablue.js:881)
at deltablue.js:888
If Error.prepareStackTrace holds a function this function is used to
format the stack trace, for instance allowing code generators to
customize the way stack traces are reported to make them easier to
process.
Next step: performance measurements to see if it is feasible to turn
this on by default.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2302 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
