- 23 Jun, 2014 1 commit
-
-
verwaest@chromium.org authored
BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/332863003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/333013002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jun, 2014 2 commits
-
-
danno@chromium.org authored
R=verwaest@chromium.org Review URL: https://codereview.chromium.org/300283002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21746 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
danno@chromium.org authored
Due to assorted failures R=mstarzinger@chromium.org TBR=mstarzginer@chromium.org Review URL: https://codereview.chromium.org/329463005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21732 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Jun, 2014 1 commit
-
-
danno@chromium.org authored
R=verwaest@chromium.org Review URL: https://codereview.chromium.org/300283002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21720 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 3 commits
-
-
rmcilroy@chromium.org authored
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
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
adamk@chromium.org authored
This allows code like this: var map = new Map(); map.set(1, 'One'); ... var iter = map.values(); var res; while (!(res = iter.next()).done) { print(res.value); } BUG=v8:1793 LOG=Y R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/259883002 Patch from Erik Arvidsson <arv@chromium.org>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21615 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 May, 2014 1 commit
-
-
adamk@chromium.org authored
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
-
- 09 May, 2014 1 commit
-
-
verwaest@chromium.org authored
BUG= R=ishell@chromium.org Review URL: https://codereview.chromium.org/265763007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21233 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2014 1 commit
-
-
mvstanton@chromium.org authored
The fix is to make the code aging sequence hang off the isolate. BUG=v8:3303 R=svenpanne@chromium.org LOG=N Review URL: https://codereview.chromium.org/261953002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21165 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 May, 2014 1 commit
-
-
ishell@chromium.org authored
Map::Normalize() introduced as single entry point for map normalization and Map::NotifyLeafMapLayoutChange() made private. R=verwaest@chromium.org Review URL: https://codereview.chromium.org/263663002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Apr, 2014 2 commits
-
-
yangguo@chromium.org authored
R=hpayer@chromium.org Review URL: https://codereview.chromium.org/259173003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mvstanton@chromium.org authored
LOG=N BUG=v8:3212 R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/254623002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21085 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 2 commits
-
-
ishell@chromium.org authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/251293002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21060 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Apr, 2014 1 commit
-
-
yangguo@chromium.org authored
Motivation: we do not have test coverage for debuggersupport=off. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/256653004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20969 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Apr, 2014 2 commits
-
-
bmeurer@chromium.org authored
This reverts commit r20938 for breaking the windows build. TBR=ulan@chromium.org Review URL: https://codereview.chromium.org/254463003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20939 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/257453003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20938 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Apr, 2014 1 commit
-
-
yangguo@chromium.org authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/240883003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20871 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Apr, 2014 2 commits
-
-
adamk@chromium.org authored
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 TBR=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
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/240813002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20831 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Apr, 2014 9 commits
-
-
adamk@chromium.org authored
This reverts https://code.google.com/p/v8/source/detail?r=20823 It broke Windows builds. Will need to find a Windows try bot to figure out why. TBR=mstarzinger@chromium.org,arv@chromium.org Review URL: https://codereview.chromium.org/238973011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20824 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
adamk@chromium.org authored
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
-
rossberg@chromium.org authored
Just wanted to add two constructors to a datatype, how ugly can it get? R=bmeurer@chromium.org, jarin@chromium.org BUG= Committed: https://code.google.com/p/v8/source/detail?r=20809 Committed: https://code.google.com/p/v8/source/detail?r=20815 Review URL: https://codereview.chromium.org/228263005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20817 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
TBR=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/237963016 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20816 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
Just wanted to add two constructors to a datatype, how ugly can it get? R=bmeurer@chromium.org, jarin@chromium.org BUG= Committed: https://code.google.com/p/v8/source/detail?r=20809 Review URL: https://codereview.chromium.org/228263005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20815 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
TBR=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/240143003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20810 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
Just wanted to add two constructors to a datatype, how ugly can it get? R=bmeurer@chromium.org, jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/228263005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20809 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
adamk@chromium.org authored
This reverts commit https://code.google.com/p/v8/source/detail?r=20781. It broke the Win32 builders. TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/239163012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20782 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
adamk@chromium.org authored
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
-
- 15 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
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
-
- 14 Apr, 2014 2 commits
-
-
jarin@chromium.org authored
Revert r20701. TBR=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/236843002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20704 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
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
-
- 11 Apr, 2014 1 commit
-
-
ulan@chromium.org authored
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
-
- 08 Apr, 2014 2 commits
-
-
adamk@chromium.org authored
This also deletes ObjectHashSet as it's no longer used. BUG=v8:1793 LOG=N R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/225183009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/228093004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20572 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/227473002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20531 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Apr, 2014 1 commit
-
-
yangguo@chromium.org authored
Often, when we call MaybeObject::Verify, what we want is Object::ObjectVerify. R=hpayer@chromium.org Review URL: https://codereview.chromium.org/218993005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20382 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Mar, 2014 1 commit
-
-
dslomov@chromium.org authored
R=mvstanton@chromium.org, verwaest@chromium.org Review URL: https://codereview.chromium.org/150813004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20279 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-