Refresh the implementation of Symbols to catch up with what the
specification now mandates:
* The global Symbol() function manufactures new Symbol values,
optionally with a string description attached.
* Invoking Symbol() as a constructor will now throw.
* ToString() over Symbol values still throws, and
Object.prototype.toString() stringifies like before.
* A Symbol value is wrapped in a Symbol object either implicitly if
it is the receiver, or explicitly done via Object(symbolValue) or
(new Object(symbolValue).)
* The Symbol.prototype.toString() method no longer throws on Symbol
wrapper objects (nor Symbol values.) Ditto for Symbol.prototype.valueOf().
* Symbol.prototype.toString() stringifies as "Symbol("<description>"),
valueOf() returns the wrapper's Symbol value.
* ToPrimitive() over Symbol wrapper objects now throws.
Overall, this provides a stricter separation between Symbol values and
wrapper objects than before, and the explicit fetching out of the
description (nee name) via the "name" property is no longer supported
(by the spec nor the implementation.)
Adjusted existing Symbol test files to fit current, adding some extra
tests for new/changed behavior.
LOG=N
R=arv@chromium.org, rossberg@chromium.org, arv, rossberg
BUG=v8:3053
Review URL: https://codereview.chromium.org/118553003
Patch from Sigbjorn Finne <sigbjornf@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Code generation would fail when assembling a branch to a label that is bound
outside the immediate range of the instruction. A64 is sensitive to this, as the
various branching instructions have different ranges, going down to +-32KB for
TBZ/TBNZ. The MacroAssembler is augmented to handle branches to targets that
may exceed the immediate range of instructions.
When branching backward to a label exceeding the instruction range, the
MacroAssembler can simply tweak the generated code to use an unconditional
branch with a longer range. For example instead of
B(cond, &label);
the MacroAssembler can generate:
b(InvertCondition(cond), &done);
b(&label);
bind(&done);
Since the target is not known when the branch is emitted, forward branches uses
a different mechanism. The MacroAssembler keeps track of forward branches to
unbound labels. When the code generation approaches the end of the range of a
branch, a veneer is generated for the branch.
BUG=v8:3148
LOG=Y
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/169893002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Arithmetic right shifting is *not* division in two's complement
representation, only in one's complement. So we convert to one's
complement, shift, and go back to two's complement. By permutating the
last steps, one can get efficient branch-free code. This insight comes
from the paleozoic era of computer science, see the paper from 1976:
Guy Lewis Steele Jr.: "Arithmetic Shifting Considered Harmful"
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-378.pdf
This results in better and more correct code than our previous
"neg/shift/neg" dance.
LOG=y
BUG=v8:3151
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/166793002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The fix removes wrong simulates from the number branch of polymorphic
call/field access handling.
The change also fixes the same thing for polymorphic named field
access even thourgh the field access is probably safe in practice
(because it cannot deoptimize). It is better to keep all our simulates
in sync with full codegen.
R=jkummerow@chromium.org
BUG=
Review URL: https://codereview.chromium.org/166503002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19375 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
-schedule a microtask (EnqueueExternalMicrotask)
-run the microtask queue (RunMicrotasks)
-control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
BUG=
Review URL: https://codereview.chromium.org/154283002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ES6 makes the Function object properties "length" and "name"
configurable; switch the implementation over to follow that.
Doing so exposed a problem in the handling of non-writable, but
configurable properties backed by foreign callback accessors
internally. As an optimization, if such an accessor property is
re-defined with a new value, its setter was passed the new value
directly, keeping the property as an accessor property. However, this
is not correct should the property be non-writable, as its setter will
then simply ignore the updated value. Adjust the enabling logic for
this optimization accordingly, along with adding a test.
LOG=N
R=rossberg@chromium.org, rossberg
BUG=v8:3045
Review URL: https://codereview.chromium.org/116083006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19200 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Committed: https://code.google.com/p/v8/source/detail?r=18918
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Throwing under FLAG_debug_code confuses the rest of our infrastructure
which expects a safe point at the site of call into the runtime
for throw. We were doing that to make a clusterfuzz test happy, but
the better solution is to assert/abort under debug_code, and prevent
clusterfuzz from fuzzing on internal APIs that crash on incorrect
values.
We'll need to alter the fuzzer to turn off fuzzing for:
string-natives.js
lithium/SeqStringSetChar.js
regress/regress-seqstrsetchar-ex3.js
regress/regress-seqstrsetchar-ex1.js
regress/regress-crbug-320922.js
So as to prevent the fuzzer from running
%_OneByteSeqStringSetChar() and
%_TwoByteSeqStringSetChar().
BUG=
R=hpayer@chromium.org, machenbach@chromium.org
Review URL: https://codereview.chromium.org/139903005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts:
r18749 "Reland (and fix) "Add hydrogen support for ArrayPop, and remove the handwritten call stubs."",
r18790 "Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft.", and
r18798 "MIPS: Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft."
For causing crashes on Canary.
BUG=chromium:337686
LOG=N
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/146003006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18805 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We removed an HDiv by hand which was still used by an HChange. The
solution is letting dead code removal do the cleanup.
Removed a fragile "optimization" (looking through an HChange), too,
this obviously never triggered and is hard to get right given all our
global invariants and state/type/... changes.
The repro is a bit tricky, because you need inlining to make our
representations and types disagree in this case.
LOG=y
BUG=334708
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/143903016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18737 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
