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
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
This is an initial step towards tracking the exact types instead of just
the representations of fields. It adds support to track up to one map of
heap object field values, eliminating various map checks on values
loaded from such fields, at the cost of making stores to such fields
slightly more expensive.
Issues with transitioning stores and fast object literals in Crankshaft
fixed.
TEST=mjsunit/field-type-tracking
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/238773002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20746 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is an initial step towards tracking the exact types instead of just the representations of fields. It adds support to track up to one map of heap object field values, eliminating various map checks on values loaded from such fields, at the cost of making stores to such fields slightly more expensive.
TEST=mjsunit/field-type-tracking
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/167303005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20701 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Maps in monomorphic Load, KeyedLoad, Store, KeyedStore, and CompareNil IC
stubs are treated as weak references by the marking visitor.
During generation of an IC stub with a weak map, the stub is appended to the
dependent code array of the map. When the map dies, all stubs in its dependent
code array are invalidated by setting embedded maps to undefined.
BUG=v8:2073
LOG=Y
TEST=cctest/test-heap/WeakMapInMonomorphic*IC
R=mstarzinger@chromium.org, verwaest@chromium.org
Review URL: https://codereview.chromium.org/188783003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20679 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Attempting to re-use the type feedback vector stored in the
SharedFunctionInfo turns out to be difficult among the various cases.
It will be much easier to do this when deferred type feedback processing
is removed, as is in the works.
Created bug v8:3212 to track re-introducing the optimization of reusing
the type vector on recompile before optimization.
The CL also brings back the type vector on the SharedFunctionInfo.
BUG=351257
LOG=Y
R=bmeurer@chromium.org, bmeuer@chromium.org
Review URL: https://codereview.chromium.org/199973004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
