Port r14061 (df49702a)
Original commit message:
If we find a property in the prototype-chain that we can overwrite, and
we have a transition, keep the holder in the lookup-result as the actual
holder. We will need it for the consistency-check in GenerateStoreField.
By directly checking the entire chain we avoid having to lazily bail out
to a copy of the miss stub while generating the Field Store IC.
Currently this CL disallows a normal non-receiver holder, given that
that would require a positive lookup + details verification to ensure
the property did not become read-only. This fixes the regressions in the
attached tests.
BUG=
Review URL: https://codereview.chromium.org/12924011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14070 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14051 (e9140a92)
Original commit message:
(qua last week's TC39)
Specifically:
- Install Symbol constructor function on the global object.
- Adjust code generation for typeof.
- Remove IsSymbol built-in, IS_SYMBOL macro now defined using typeof.
- Remove hack that allowed symbols as constructor results, and some other special cases.
- Remove symbol_delegate and GetDelegate function.
- Extend ToBoolean stub to handle symbols.
- Extend ToNumber to return NaN on symbols.
- Poison symbol's toString function, and thereby ToString on symbols.
BUG=
Review URL: https://codereview.chromium.org/13007003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14058 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14001 (28443693)
Original commit message:
- Addition of a compiled hydrogen stub for KeyedStores.
- Inlining of "grow" stubs into OPTIMIZED_FUNCTIONs
- Addition of new "ignore OOB" ic stub that silently swallows out-of-bounds stores to external typed arrays.
- Addition of new "copy-on-write" ic stub that inlines allocation and copying operations for cow array
- New stub are generated with Crankshaft, so they are automatically inlined into OPTIMIZED_FUNCTIONs
BUG=
Review URL: https://codereview.chromium.org/12702012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14018 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Minor cleanups on the way, e.g. making sure that we never use something after an allocation failed. Style question: Should we switch to some kind of MUST_USE_RESULT-style to ensure that we handle failures consistently? Not sure...
BUG=v8:2576
Review URL: https://codereview.chromium.org/12867002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13946 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13887 (6d146270)
Original commit message:
This unifies the translation of a compiled stub frame to a stub failure
trampoline frame. Only the frame's register allocation is different on
each architecture and can be factored out.
BUG=
Review URL: https://codereview.chromium.org/12756002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13893 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13811 (0e64f280)
Original commit message:
Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
BUG=
Review URL: https://codereview.chromium.org/12561003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13874 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13786 (b5e7a82a)
Original commit message:
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
BUG=
Review URL: https://codereview.chromium.org/12447009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13871 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
First of all, it has nothing to do with Isolates, it is related to the assembler
at hand. Furthermore, the saving/restoring is platform-independent. Cleaned up
some platform-specific stuff on the way.
Note that there are some things which still need some cleanup, like e.g. using
EnumSet instead of uint64_t, making Probe() more uniform across platforms etc.,
but the CL is already big enough.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12391055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13781 (59f39a06)
Original commit message:
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
BUG=
Review URL: https://codereview.chromium.org/12374074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13807 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13768 (4996bcd0)
Original commit message:
- Later the different parts will become individual code objects that tailcall into one another.
- The mapcheck/symbol check still needs to be separated from the overall prototype-chain check so that the ICs can reuse the handlers.
BUG=
Review URL: https://codereview.chromium.org/12378061
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13804 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13763 (6b32e7d6)
Original commit message:
This fixes the deoptimizer to materialize arguments objects of correct
length even in cases where the actual argument values are unknown and
were optimized away by Crankshaft. This can happen if only the length
property or the identity of an arguments object is used.
BUG=
Review URL: https://codereview.chromium.org/12383076
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13803 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13732 (686b0a45)
Original commit message:
This changes FastCloneShallowObjectStub to be compiled independent of
the target architecture. It also adds tracing to the deoptimizer for
compiled stubs and contains some minor bugfixes.
BUG=
Review URL: https://codereview.chromium.org/12389070
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13585 (4174b9d2)
Original commit message:
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/12212080
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13655 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Initial step towards separating IC (map check(s)), handler frontend
(prototype-check) and handler backend (actual handler code).
- Still need to split the map-check (IC) from rest of the prototype
chain check.
- Still need to turn different parts in own code objects and cache them
in more optimal places.
Review URL: https://chromiumcodereview.appspot.com/12207016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13604 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13533 (2f339757)
Original commit message:
In preparation of supporting stubs that deopt and then need to push their
register-based parameters to an arguments area on the stack that gets properly
collected, add StubFailureTrampolineFrames to hold those parameters.
BUG=
TEST=
Review URL: https://codereview.chromium.org/12087053
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13560 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13475 (0076e1ee)
Original commit message:
With parallel recompilation enabled, objects made accessible by handles may
have changed between graph construction and graph optimization. Therefore
we must not assume that information on those objects remain the same between
those two phases. To police this, we forbid handle dereferencing during
graph optimization.
Exceptions to this rule are:
- Dereferencing the handle to obtain the raw location of the object. This
is safe since parallel recompilation acquires RelocationLock
- Some places that dereference the handle for a type check. These are checked
to be safe on a case-by-case basis.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/12049037
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13477 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13454 (2c0dd0ff)
Original commit message:
HCheckPrototypeMaps currently records the prototype and the holder of the
prototype chain (both ends of the chain) and assumes that the chain elements
and their maps did not change in during the entirety of Crankshaft. The actual
traversal of the prototype chain happens in Lithium at code generation.
With parallel compilation, this assumption is not longer correct.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/12036030
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r13462 (74f0ddf6)
Original commit message:
Incorrect ARM assembly in MacroAssembler::TestJSArrayForAllocationSiteInfo Restored test code in allocation-site-info.js that was failing on ARM because of this bug.
BUG=
TEST=
Review URL: https://codereview.chromium.org/11896037
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13465 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
