- 26 Aug, 2015 2 commits
-
-
mstarzinger authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1314053003 Cr-Commit-Position: refs/heads/master@{#30385}
-
mstarzinger authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1312413002 Cr-Commit-Position: refs/heads/master@{#30384}
-
- 18 Aug, 2015 1 commit
-
-
mstarzinger authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1293053004 Cr-Commit-Position: refs/heads/master@{#30232}
-
- 11 Aug, 2015 1 commit
-
-
bmeurer authored
This way we can greatly simplify the different variants of ToObject in our codebase and make them more uniform and robust. Adding a new primitive doesn't require finding and changing all those places again, but it is sufficient to setup the constructor function index when allocating the map. We use the inobject properties field of Map, which is invalid primitive maps anyway. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1276533003 Cr-Commit-Position: refs/heads/master@{#30119}
-
- 23 Jun, 2015 1 commit
-
-
adamk authored
Map: get, set, has, delete, clear Set: add, has, delete, clear All except clear are implemented as calls into collection.js. Note that some of these shadow methods of v8::Object. It's unclear how confusing that's going to be: on the one hand, it seems likely that most operations you would want to do on a Map or Set are these. On the other, generic code could get confused if it somehow gets ahold of a variable that happens to be C++-typed as a v8::Map or v8::Set. BUG=v8:3340 LOG=y Review URL: https://codereview.chromium.org/1204623002 Cr-Commit-Position: refs/heads/master@{#29237}
-
- 26 May, 2015 2 commits
-
-
adamk authored
Only supports constructing new objects and returning size. Followup patch will need to add ability to retrieve and set contents in order to support structured clone. Also removes a bunch of outdated "experimental" markers from v8.h. BUG=v8:3340 LOG=y Review URL: https://codereview.chromium.org/1157453002 Cr-Commit-Position: refs/heads/master@{#28637}
-
erikcorry authored
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
-
- 20 May, 2015 1 commit
-
-
erikcorry authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1143133002 Cr-Commit-Position: refs/heads/master@{#28502}
-
- 11 May, 2015 1 commit
-
-
danno authored
This stub will be used as the basis of a Math.floor-specific CallIC to detect and track calls to floor that return -0. Along the way: - Create a TurboFanCodeStub super class from which the StringLength and MathRound TF stubs derive. - Fix the ugly hack that passes the first stub parameter as the "this" pointer in the the TF-compiled JS function. - Fix bugs in the ia32/x64 disassembler. Review URL: https://codereview.chromium.org/1137703002 Cr-Commit-Position: refs/heads/master@{#28339}
-
- 17 Apr, 2015 1 commit
-
-
jkummerow authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1091253002 Cr-Commit-Position: refs/heads/master@{#27921}
-
- 07 Apr, 2015 1 commit
-
-
adamk authored
Previously, the only optimized code path for Maps and Sets was for String keys. This was achieved through an implementation of various complex operations in Hydrogen. This approach was neither scalable nor forward-compatible. This patch adds the necessary intrinsics to implement Maps and Sets almost entirely in JS. The added intrinsics are: %_FixedArrayGet %_FixedArraySet %_TheHole %_JSCollectionGetTable %_StringGetRawHashField With these additions, as well as a few changes to what's exposed as runtime functions, most of the C++ code backing Maps and Sets is gone (including both runtime code in objects.cc and Crankshaft in hydrogen.cc). Review URL: https://codereview.chromium.org/947683002 Cr-Commit-Position: refs/heads/master@{#27605}
-
- 05 Feb, 2015 1 commit
-
-
yurys authored
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context. BUG=chromium:437416 LOG=Y Review URL: https://codereview.chromium.org/900123003 Cr-Commit-Position: refs/heads/master@{#26451}
-
- 04 Feb, 2015 2 commits
-
-
yurys authored
Revert of Add WeakKeyMap to v8.h (patchset #2 id:20001 of https://codereview.chromium.org/891473005/) Reason for revert: Revert this patch due to shared win build compilation failure http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/5030/steps/compile/logs/stdio Original issue's description: > Add WeakKeyMap to v8.h > > A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context. > > BUG=chromium:437416 > LOG=Y > > Committed: https://crrev.com/ee7ed39ac8327124e74dd7ad5f1de0dede988cb7 > Cr-Commit-Position: refs/heads/master@{#26425} TBR=jochen@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:437416 Review URL: https://codereview.chromium.org/901663002 Cr-Commit-Position: refs/heads/master@{#26430}
-
yurys authored
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context. BUG=chromium:437416 LOG=Y Review URL: https://codereview.chromium.org/891473005 Cr-Commit-Position: refs/heads/master@{#26425}
-
- 03 Feb, 2015 2 commits
-
-
https://codereview.chromium.org/886473005/yurys authored
Reason for revert: Broke compilation on component build http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/5007/steps/compile/logs/stdio Original issue's description: > Add WeakMap to v8.h > > A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context. > > BUG=chromium:437416 > LOG=Y > > Committed: https://crrev.com/37d4c57630636f21e3add8d3d1c7c978ff5fc8e0 > Cr-Commit-Position: refs/heads/master@{#26401} TBR=jochen@chromium.org,mstarzinger@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:437416 Review URL: https://codereview.chromium.org/898763002 Cr-Commit-Position: refs/heads/master@{#26402}
-
yurys authored
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context. BUG=chromium:437416 LOG=Y Review URL: https://codereview.chromium.org/886473005 Cr-Commit-Position: refs/heads/master@{#26401}
-
- 05 Dec, 2014 1 commit
-
-
ulan authored
This fixes mjsunit/es6/mirror-collections failure in arm64 gc-stress bot. BUG= Review URL: https://codereview.chromium.org/783673002 Cr-Commit-Position: refs/heads/master@{#25687}
-
- 17 Nov, 2014 1 commit
-
-
Andrey Adaikin authored
R=yangguo@chromium.org, vsevik LOG=Y Committed: https://code.google.com/p/v8/source/detail?r=d5f5d38f73f43eba9658d91ffbe511af8c340d78 Review URL: https://codereview.chromium.org/710273002 Cr-Commit-Position: refs/heads/master@{#25380}
-
- 11 Nov, 2014 1 commit
-
-
aandrey@chromium.org authored
R=yangguo@chromium.org LOG=N Review URL: https://codereview.chromium.org/712083002 Cr-Commit-Position: refs/heads/master@{#25257} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25257 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Nov, 2014 1 commit
-
-
aandrey@chromium.org authored
This is to show values preview of an iterator in DevTools console. API=v8::Value::IsMapIterator, v8::Value::IsSetIterator BUG=chromium:427868 R=arv@chromium.org, yangguo@chromium.org, adamk@chromium.org LOG=Y Review URL: https://codereview.chromium.org/693813002 Cr-Commit-Position: refs/heads/master@{#25100} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25100 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 31 Oct, 2014 1 commit
-
-
ulan@chromium.org authored
Not clearing can lead to a crash under following conditions: 1. Backing store of a weak map is allocated in large object space. 2. The backing store is marked incrementaly via the weak map. 3. The weak map is updated and gets a new backing store. 4. The store buffer overflows and marks the chunk of the old backing store as "scan on scavenge." 5. Mark-compact collection kills some elements of the weak map. Note that the old backing store survives because it was marked incrementally, but its dead elements are not cleared. 6. Scavenger iterates over the old backing store, tries to move a dead object and crashes. BUG=v8:3631 LOG=N TEST=cctest/test-heap/Regress3631 R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/686783003 Cr-Commit-Position: refs/heads/master@{#25032} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25032 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Oct, 2014 1 commit
-
-
yangguo@chromium.org authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/662413002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24736 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Sep, 2014 1 commit
-
-
yangguo@chromium.org authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/598913004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24274 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-