The change relative to the previous CL is a logic change in
DropActivationsInActiveThreadImpl. The previous CL skipped the matcher
unless the frame was a JS frame; this was correct for
MultipleFunctionTarget but not for SingleFrameTarget.
I have not been able to reproduce the original failures on either
architecture (ia32 or x64; stack frame dropping is unsupported on other
architectures).
R=yangguo@chromium.org
LOG=N
TEST=mjsunit/harmony/generators-debug-liveedit.js
BUG=
Review URL: https://codereview.chromium.org/270283002
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21419 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This changes how Map/Set interacts with its iterators. When the
underlying table is rehashed or cleared, we create a new table (like
before) but we add a reference from the old table to the new table. We
also add an array describing how to transition the iterator from the
old table to the new table.
When Next is called on the iterator it checks if there is a newer table
that it should transition to. If there is, it updates the index based
on the previously recorded changes and finally changes itself to point
at the new table.
With these changes Map/Set no longer keeps the iterators alive. Also,
as before, the iterators keep the underlying table(s) alive but not the
actual Map/Set.
BUG=v8:1793
LOG=Y
R=mstarzinger@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/289503002
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793, 2323
LOG=Y
R=adamk@chromium.orgTBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/238063009
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20857 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793,2323
LOG=Y
TBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/240323003
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793,2323
LOG=Y
R=adamk@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/236143002
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
From ES6 rev20 draft, closed generator returns completed object (the
value is `undefined` and done is `true`).
Since a error thrown in generator is propagated to the caller without
setting status of a thrown generator to "completed", once a generator is
suspended by a error, status becomes "executing" forever. This is filed
as v8:3096
LOG=N
BUG=v8:3097
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/136003003
Patch from Yusuke Suzuki <yusukesuzuki@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18591 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Based on prototype at
https://github.com/rossberg-chromium/js-promise
which informed the latest spec draft version at
https://github.com/domenic/promises-unwrapping/blob/master/README.md
Activated by --harmony-promises.
Feature complete with respect to the draft spec, plus the addition of .when and .deferred methods. Final naming and other possible deviations from the current draft will hopefully be resolved soon after the next TC39 meeting.
This CL also generalises the Object.observe delivery loop into a simplistic microtask loop. Currently, all observer events are delivered before invoking any promise handler in a single fixpoint iteration. It's not clear yet what the final semantics is supposed to be (should there be a global event ordering?), but it will probably require a more thorough event loop abstraction inside V8 once we get there.
R=dslomov@chromium.org, yhirano@chromium.org
BUG=
Review URL: https://codereview.chromium.org/64223010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Adds a notion of private symbols, mainly intended for internal use, especially, self-hosting of built-in types that would otherwise require new C++ classes.
On the JS side (i.e., in built-ins), private properties can be created and accessed through a set of macros:
NEW_PRIVATE(print_name)
HAS_PRIVATE(obj, sym)
GET_PRIVATE(obj, sym)
SET_PRIVATE(obj, sym, val)
DELETE_PRIVATE(obj, sym)
In the V8 API, they are accessible via a new class Private, and respective HasPrivate/Get/Private/SetPrivate/DeletePrivate methods on calss Object.
These APIs are designed and restricted such that their implementation can later be replaced by whatever ES7+ will officially provide.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/48923002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
https://codereview.chromium.org/19541010/
The main problem is that if you called Object.getNotifier(obj) on an object, %SetObserved(object) would never get called on it, and thus it would be unobservable (new test added for this).
Additionally, Runtime::SetObserved was asserting obj->IsJSObject() which would fail if called on a proxy.
It just happens that our existing test always called getNotifier() before Object.observe on proxies, and thus we never previously attempted to transition the map of a proxy.
Both issues are now fixed and properly tested.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/21891008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
