Revert "Fix for an assertion failure in Map::FindTransitionToField(...). Appeared after r25136."
This revert is made in order to revert r25099 which potentially causes renderer hangs.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/722873004
Cr-Commit-Position: refs/heads/master@{#25332}
This CL adds support for ConstantPoolArrays which contain an extended section.
This will be used to enable larger constant pools than can be addressed by a
single ldr with immediate offset instruction (which has a limit of a 4KB range).
Extended constant pools will have a small section, which is addressable via a
single ldr instruction, and an extended section, which will require a multi-
instruction sequence to load from.
Currently, no code uses the extended ConstantPoolArray's - this change will
be made in a followup CL.
A number of changes are made to the ConstantPoolArray object in order to
support this:
- Small section layout is now entirely defined by the small layout bitmaps.
- The ConstantPoolArray no longer extends FixedArrayBase since the length
field is not useful for extended layouts.
- Enums are used to represent the type of an entry and the layout section.
- An iterator can be used to iterate through all elements of a given type.
- A number of tests were added for these features.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/304143002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21653 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
