This includes:
- actually release handles kept by compilation info when compilation completes.
- do not use parallel recompilation on single core CPUs.
- artificially delay parallel recompilation for debugging.
- fix outdated assertions wrt optimization status.
- add "parallel" option to %OptimizeFunctionOnNextCall.
R=jkummerow@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/12442002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13827 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a temporary workaround when the __proto__ property is being
redefined (e.g. by Object.freeze()) to not loose the foreign callback.
Once the __proto__ property is a real JavaScript accessor this hack is
no longer necessary. This change also makes __proto__ configurable.
R=rossberg@chromium.org
BUG=v8:2565
TEST=mjsunit/regress/regress-2565
Review URL: https://codereview.chromium.org/12398010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13817 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- 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/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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.
R=svenpanne@chromium.org
BUG=chromium:163530
TEST=mjsunit/regress/regress-crbug-163530
Review URL: https://codereview.chromium.org/12335132
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13763 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This moves the __proto__ property to Object.prototype and turns it into
a callback property actually present in the descriptor array as opposed
to a hack in the properties lookup. For now it still is a "magic" data
property using foreign callbacks and not an accessor property visible to
JavaScript.
The second effect of this change is that JSON.parse() no longer treats
the __proto__ property specially, it will be defined as any other data
property. Note that object literals still have their special handling.
R=rossberg@chromium.org
BUG=v8:621,v8:1949,v8:2441
TEST=mjsunit,cctest,test262
Review URL: https://codereview.chromium.org/12212011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13728 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows Crankshaft to completely inline a f.apply() dispatch if the
exact number of arguments is known and the function is constant. The
deoptimizer doesn't generate the f.apply() frame during deoptimization,
so the materialized frames look like f.apply() did a tailcall.
R=jkummerow@chromium.org
TEST=mjsunit/compiler/inline-function-apply
Review URL: https://codereview.chromium.org/12263004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a data property has its attributes changed but its value remains the same,
don't emit an oldValue. This makes the API more consistent by only emitting
oldValue when the value of a property has actually changed (or been removed,
in the case of a reconfiguration as an accessor property or a deletion).
Review URL: https://codereview.chromium.org/11820004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13565 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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.
R=mstarzinger@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/11864013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
