Access to an ExternalReference in non-serializable code will try to use
an offset relative to the root-array register.
Since the root-array is in the Heap object, and the Heap object is in
the Isolate object, there's a good chance that any external data field
is within a 32-bit offset of the root array register.
It falls back on the original behavior if the serializer is enabled,
if the root register isn't initialized or if the offset is not representable
as a 32-bit value.
Review URL: http://codereview.chromium.org/6716018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7315 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
we know that both sides are Smi and those where we don't. Fix inlined
symbol table probes to cope with strings, undefined and null (indicating
a deleted entry). Some changes to other architectures that were found
with the new asserts.
Review URL: http://codereview.chromium.org/6682026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7172 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ensure that there is always enough bytes between consequtive calls in
unoptimized code to write a call instruction at the return points
without overlapping.
This handles the case where two return points were only four bytes
apart (because the latter call was to a register).
BUG=v8:1234
Review URL: http://codereview.chromium.org/6624091
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7089 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
inline allocation code used the expected number of properties to
calculate the number of inobject properties for an object instead of
getting the actual number from the initial map.
It is safer to use the inobject property count from the initial map in
any case because that is the amount the instances will get. I think
this disconnect got introduced when adding shrinking of objects.
Unfortuntely I haven't been able to create a simple reproduction for a
test case but this fixes the webpage that exhibits the crash. I'll see
if I can create a reproduction tomorrow.
Review URL: http://codereview.chromium.org/5278003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The live registers are now only stored to the expression stack with the non pointer values being stored as smis (on the 32-bit platforms these values are assumed to be 31-bit max).
This makes the CEntryStub entry/exit code much simpler, and there is no longer any need for a mode (debug or normal) on it.
Fix a missing live register when breaking at ARM keyed load.
Review URL: http://codereview.chromium.org/3141047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5358 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Object model changes
----------------------------------------
New fixed_cow_array_map is used for the elements array of a JSObject
to mark it as COW. The JSObject's map and other fields are not
affected. The JSObject's map still has the "fast elements" bit set. It
means we can do only the receiver map check in keyed loads and the
receiver and the elements map checks in keyed stores. So introducing
COW arrays doesn't hurt performance of these operations. But note that
the elements map check is necessary in all mutating operations because
the "has fast elements" bit now means "has fast elements for reading".
EnsureWritableFastElements can be used in runtime functions to perform
the necessary lazy copying.
Generated code changes
----------------------------------------
Generic keyed load is updated to only do the receiver map check (this
could have been done earlier). FastCloneShallowArrayStub now has two
modes: clone elements and use COW elements. AssertFastElements macro
is added to check the elements when necessary. The custom call IC
generators for Array.prototype.{push,pop} are updated to avoid going
to the slow case (and patching the IC) when calling the builtin should
work.
COW enablement
----------------------------------------
Currently we only put shallow and simple literal arrays in the COW
mode. This is done by the parser.
Review URL: http://codereview.chromium.org/3144002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds a check to the fast case string add to ensure that the String object still have the default valueOf function. The default valueOf is sitting on a hidden prototype of String.prototype.
Before using the fast case valueOf the object is checked for a local valueOf property. For slow case objects this check always reports true (the dictionary is not probed, so valueOf might be there) and for fast case objects the descriptor array is checked for the valueOf symbol (just liniar scan). After that the prototype is checked for beeing the initial value of String.prototype. If this all pass (that is the default valueOf is still in place) this result is cached on the map making the check fast the next time.
This is only implemented in the optimizing compiler, as the two usages of %_IsStringWrapperSafeForDefaultValueOf is never hit by the full compiler.
I will port to x64 and ARM when this has been reviewed for ia32.
I will remove the performance counters prior to final commit.
BUG=http://code.google.com/p/v8/issues/detail?id=760
TEST=test/mjsunit/regress/regress-760-1.js
TEST=test/mjsunit/regress/regress-760-2.js
Review URL: http://codereview.chromium.org/3117006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5252 ce2b1a6d-e550-0410-aec6-3dcde31c8c00