- 03 Aug, 2018 1 commit
-
-
Clemens Hammacher authored
arguments.h used methods only defined in objects-inl.h and handles-inl.h. These uses are now moved to arguments-inl.h. Since builtins-utils.h used these methods, it also needs to be split to have an inl header now. R=titzer@chromium.org Bug: v8:7754, v8:7965 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I21db7a86f7c15776eccf060f81f2bde000b92a40 Reviewed-on: https://chromium-review.googlesource.com/1160647Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54889}
-
- 31 Jul, 2018 1 commit
-
-
Camillo Bruni authored
Bug: v8:7942 Change-Id: I7b3740b04cbcaa56dc809150900ab8d821b054ce Reviewed-on: https://chromium-review.googlesource.com/1156544Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#54821}
-
- 31 May, 2018 1 commit
-
-
Dan Elphick authored
Removes all explicit calls to GetIsolate() in runtime/ by passing it through calling function functions and implicit calls via the single argument Handle constructor and handle function. Bug: v8:7786 Change-Id: I96ac2289a72a42c7abb6754418fecb8e03f2bb29 Reviewed-on: https://chromium-review.googlesource.com/1080528 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#53457}
-
- 24 May, 2018 1 commit
-
-
Marja Hölttä authored
Moving them away was a mistake. Fixing this enables getting rid of a bunch of includes. BUG=v8:5402 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I5482eab4281c7450350f058fe0a04a6f375ea082 Reviewed-on: https://chromium-review.googlesource.com/1070188Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#53328}
-
- 09 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
There is no good reason to have the meat of most objects' initialization logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, this CL changes the protocol between Heap and Factory to be AllocateRaw, and all object initialization work after (possibly retried) successful raw allocation happens in the Factory. This saves about 20KB of binary size on x64. Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533 Originally landed as r52416 / f9a2e24b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id072cbe6b3ed30afd339c7e502844b99ca12a647 Reviewed-on: https://chromium-review.googlesource.com/1000540 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52492}
-
- 06 Apr, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit f9a2e24b. Reason for revert: gc stress failures not all fixed by follow up. Original change's description: > [cleanup] Refactor the Factory > > There is no good reason to have the meat of most objects' initialization > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, > this CL changes the protocol between Heap and Factory to be AllocateRaw, > and all object initialization work after (possibly retried) successful > raw allocation happens in the Factory. > > This saves about 20KB of binary size on x64. > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca > Reviewed-on: https://chromium-review.googlesource.com/959533 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52416} TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52420}
-
Jakob Kummerow authored
There is no good reason to have the meat of most objects' initialization logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, this CL changes the protocol between Heap and Factory to be AllocateRaw, and all object initialization work after (possibly retried) successful raw allocation happens in the Factory. This saves about 20KB of binary size on x64. Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca Reviewed-on: https://chromium-review.googlesource.com/959533 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52416}
-
- 28 Feb, 2018 1 commit
-
-
Georg Neis authored
For namespace objects, [[GetOwnProperty]] on an uninitialized property throws a ReferenceError. This was not implemented everywhere. This CL fixes all such issues I'm aware of. Bug: v8:7470 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I5f024450005c4f4dcb3f41c844ef055f67a9a869 Reviewed-on: https://chromium-review.googlesource.com/937341Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51638}
-
- 01 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
-
- 30 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
Introduce a proper empty_descriptor_array, which has the proper layout (length is 2 and the two fields are set properly). Also add a special EnumCache class and a matching empty_enum_cache. The contract now is that we only need to check the EnumLength on the map to know whether we are allowed to use the enum cache. This greatly simplifies the handling of the enum cache (and also the descriptor arrays), especially for the future work on optimizing keyed access via the enum cache indices. Bug: v8:6702 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83 Reviewed-on: https://chromium-review.googlesource.com/641030 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47697}
-
- 24 Mar, 2017 1 commit
-
-
Toon Verwaest authored
[runtime] Immediately set the array-index hash in Uint32ToString and convert to string in ForInPrepare This speeds up for/in over arrays. E.g.,: function f(a) { for (let i in a) { if (a[i] != a[i]) print(false); } } var a = new Array(10000000); a.fill(1); f(a); runs 3x faster after the change. BUG=chromium:703226 Change-Id: Iabc5e931d985a03f89440cd702b2feb3eb9f5c18 Reviewed-on: https://chromium-review.googlesource.com/459538Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#44108}
-
- 08 Feb, 2017 1 commit
-
-
cbruni authored
Review-Url: https://codereview.chromium.org/2684043002 Cr-Commit-Position: refs/heads/master@{#43040}
-
- 29 Aug, 2016 1 commit
-
-
bmeurer authored
These JavaScript operators were special hacks to ensure that we always operate on Smis for the magic for-in index variable, but this never really worked in the OSR case, because the OsrValue for the index variable didn't have the proper information (that we have for the JSForInPrepare in the non-OSR case). Now that we have loop induction variable analysis and binary operation hints, we can just use JSLessThan and JSAdd instead with appropriate Smi hints, which handle the OSR case by inserting Smi checks (that are always true). Thanks to OSR deconstruction and loop peeling these Smi checks will be hoisted so they don't hurt the OSR case too much. Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since we have to lower it to JSLessThan to get the loop induction variable goodness. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289613002 Cr-Commit-Position: refs/heads/master@{#38968}
-
- 01 Aug, 2016 1 commit
-
-
cbruni authored
This CL fixes a long-standing bug with Object.keys where the enumerability check was omitted if the [ownKeys] trap is not present. The only distinction the KeyAccumulator needs is whether it collects keys for for-in (is_for_in_) or not. ForInFilter performs a separate step to filter out non-enumerable keys later-on while in all the other use-cases we have to filter keys. BUG=v8:1543, v8:5250 Review-Url: https://codereview.chromium.org/2176113009 Cr-Commit-Position: refs/heads/master@{#38199}
-
- 21 Jul, 2016 1 commit
-
-
cbruni authored
Use the ForInFilterStub directly. Hence we will only jump to the runtime for special receivers (instance_type <= LAST_SPECIAL_RECEIVER_TYPE) and for converting element indices which are not in the string cache. BUG= Review-Url: https://codereview.chromium.org/2151773002 Cr-Commit-Position: refs/heads/master@{#37934}
-
- 07 Jul, 2016 1 commit
-
-
jkummerow authored
BUG=v8:5181 Review-Url: https://codereview.chromium.org/2129563002 Cr-Commit-Position: refs/heads/master@{#37577}
-
- 14 Jun, 2016 1 commit
-
-
cbruni authored
Reland of place all remaining Oddball checks with new function (patchset #1 id:1 of https://codereview.chromium.org/2060213002/ ) Reason for revert: Cannot reproduce gc-stress failures locally. Original issue's description: > Revert of Replace all remaining Oddball checks with new function (patchset #10 id:180001 of https://codereview.chromium.org/2043183003/ ) > > Reason for revert: > failing tests > > Original issue's description: > > Replace all remaining Oddball checks with new function > > > > This CL removes the IsUndefined() and Co. methods from Object and HeapObject. > > The new method all take the isolate as parameter. > > > > BUG= > > > > Committed: https://crrev.com/ccefb3ae5fe967288d568013fb04e8761eafebc5 > > Cr-Commit-Position: refs/heads/master@{#36921} > > TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG= > > Committed: https://crrev.com/33b8bc24a12fb062100c0be84456faeb0b9fa5d1 > Cr-Commit-Position: refs/heads/master@{#36923} TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org BUG= Review-Url: https://codereview.chromium.org/2059173002 Cr-Commit-Position: refs/heads/master@{#36957}
-
- 13 Jun, 2016 2 commits
-
-
cbruni authored
Revert of Replace all remaining Oddball checks with new function (patchset #10 id:180001 of https://codereview.chromium.org/2043183003/ ) Reason for revert: failing tests Original issue's description: > Replace all remaining Oddball checks with new function > > This CL removes the IsUndefined() and Co. methods from Object and HeapObject. > The new method all take the isolate as parameter. > > BUG= > > Committed: https://crrev.com/ccefb3ae5fe967288d568013fb04e8761eafebc5 > Cr-Commit-Position: refs/heads/master@{#36921} TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2060213002 Cr-Commit-Position: refs/heads/master@{#36923}
-
cbruni authored
This CL removes the IsUndefined() and Co. methods from Object and HeapObject. The new method all take the isolate as parameter. BUG= Review-Url: https://codereview.chromium.org/2043183003 Cr-Commit-Position: refs/heads/master@{#36921}
-
- 08 Jun, 2016 1 commit
-
-
jkummerow authored
Adding properties to prototypes is faster when we don't force their maps into fast mode yet. Once a prototype shows up in the IC system, its setup phase is likely over, and it makes sense to transition it to fast properties. This patch speeds up the microbenchmark in the bug by 20x. Octane-Typescript sees a 3% improvement. BUG=chromium:607010 Review-Url: https://codereview.chromium.org/2036493006 Cr-Commit-Position: refs/heads/master@{#36828}
-
- 30 May, 2016 1 commit
-
-
cbruni authored
Expose more or less the full functionality of the KeyAccumulator in the API: - use the PropertyFilter introduced for GetOwnPropertyNames - use KeyCollectionLimit for OWN_ONLY or INLCUDE_PROTOS - use IndexFilter to eithe SKIP_INDICES or INCLUDE_INDICES Rewire Object::GetOwnPropertyNames to use GetPropertyNames. BUG=chromium:148757 Review-Url: https://codereview.chromium.org/2002203002 Cr-Commit-Position: refs/heads/master@{#36595}
-
- 25 May, 2016 1 commit
-
-
cbruni authored
Reland of [keys] Simplify KeyAccumulator (patchset #1 id:1 of https://codereview.chromium.org/2010593002/ ) Reason for revert: relanding, fixed handle dereferencing Original issue's description: > Revert of [keys] Simplify KeyAccumulator (patchset #15 id:280001 of https://codereview.chromium.org/1995263002/ ) > > Reason for revert: > https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/6248 > > Original issue's description: > > [keys] Simplify KeyAccumulator > > > > - Use KeyAccumulator::GetKeys directly instead of JSReceiver::GetKeys > > - Revert KeyAccumulator to single OrderedHashSet implementation. > > - Convert the OrderedHashSet in-place to a FixedArray > > - IndexedInterceptor indices are no longer combined and sorted with the object indices > > > > BUG= > > > > Committed: https://crrev.com/d3324df017046bcde247a5aef6d1b59bfae5908f > > Cr-Commit-Position: refs/heads/master@{#36485} > > TBR=jkummerow@chromium.org,verwaest@chromium.org,cbruni@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG= > > Committed: https://crrev.com/893524b53d43df63bca6cb9b7244d21771fadb0b > Cr-Commit-Position: refs/heads/master@{#36486} TBR=jkummerow@chromium.org,verwaest@chromium.org,machenbach@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2014523002 Cr-Commit-Position: refs/heads/master@{#36502}
-
- 24 May, 2016 3 commits
-
-
machenbach authored
Revert of [keys] Simplify KeyAccumulator (patchset #15 id:280001 of https://codereview.chromium.org/1995263002/ ) Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/6248 Original issue's description: > [keys] Simplify KeyAccumulator > > - Use KeyAccumulator::GetKeys directly instead of JSReceiver::GetKeys > - Revert KeyAccumulator to single OrderedHashSet implementation. > - Convert the OrderedHashSet in-place to a FixedArray > - IndexedInterceptor indices are no longer combined and sorted with the object indices > > BUG= > > Committed: https://crrev.com/d3324df017046bcde247a5aef6d1b59bfae5908f > Cr-Commit-Position: refs/heads/master@{#36485} TBR=jkummerow@chromium.org,verwaest@chromium.org,cbruni@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2010593002 Cr-Commit-Position: refs/heads/master@{#36486}
-
cbruni authored
- Use KeyAccumulator::GetKeys directly instead of JSReceiver::GetKeys - Revert KeyAccumulator to single OrderedHashSet implementation. - Convert the OrderedHashSet in-place to a FixedArray - IndexedInterceptor indices are no longer combined and sorted with the object indices BUG= Review-Url: https://codereview.chromium.org/1995263002 Cr-Commit-Position: refs/heads/master@{#36485}
-
yangguo authored
R=franzih@chromium.org Review-Url: https://codereview.chromium.org/2006673002 Cr-Commit-Position: refs/heads/master@{#36470}
-
- 23 Mar, 2016 1 commit
-
-
cbruni authored
With the recent spec change removing the [[Enumerate]] internal method, we now have to walk the complete prototype chain. This implies that we call the [[GetPrototypeOf]] trap on proxies. As a secondary change we now trigger the [[GetOwnProperty]] trap for the for-in filter step to see whether the properties are still enumerable. Before we did this in the key-accumulation phase. This way we slightly reduce the number of traps invoked. Whilst this is not ideal, it comes closer to the Spec's example implementation. BUG=v8:1543, v8:4768 LOG=n Review URL: https://codereview.chromium.org/1748923003 Cr-Commit-Position: refs/heads/master@{#35017}
-
- 07 Mar, 2016 5 commits
-
-
cbruni authored
Introducing the KeyAccumulator accidentally removed some crucial fast-paths. This CL starts rewriting the KeyAccumulator, step-by-step introducing the special cases again. BUG=chromium:545503, v8:4758 LOG=y Committed: https://crrev.com/9c61327ecb2ee41f34232632e0cac93202bae6b7 Cr-Commit-Position: refs/heads/master@{#34532} Committed: https://crrev.com/b954c872aac60657b400079b7333216ea658dc8a Cr-Commit-Position: refs/heads/master@{#34548} Review URL: https://codereview.chromium.org/1707743002 Cr-Commit-Position: refs/heads/master@{#34558}
-
cbruni authored
Revert of [key-accumulator] Starting to reimplement the key-accumulator (patchset #15 id:280001 of https://codereview.chromium.org/1707743002/ ) Reason for revert: gcmole again Original issue's description: > [key-accumulator] Starting to reimplement the key-accumulator > > Introducing the KeyAccumulator accidentally removed some crucial fast-paths. > This CL starts rewriting the KeyAccumulator, step-by-step introducing the > special cases again. > > BUG=chromium:545503, v8:4758 > LOG=y > > Committed: https://crrev.com/9c61327ecb2ee41f34232632e0cac93202bae6b7 > Cr-Commit-Position: refs/heads/master@{#34532} > > Committed: https://crrev.com/b954c872aac60657b400079b7333216ea658dc8a > Cr-Commit-Position: refs/heads/master@{#34548} TBR=verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:545503, v8:4758 Review URL: https://codereview.chromium.org/1769043003 Cr-Commit-Position: refs/heads/master@{#34551}
-
cbruni authored
Introducing the KeyAccumulator accidentally removed some crucial fast-paths. This CL starts rewriting the KeyAccumulator, step-by-step introducing the special cases again. BUG=chromium:545503, v8:4758 LOG=y Committed: https://crrev.com/9c61327ecb2ee41f34232632e0cac93202bae6b7 Cr-Commit-Position: refs/heads/master@{#34532} Review URL: https://codereview.chromium.org/1707743002 Cr-Commit-Position: refs/heads/master@{#34548}
-
cbruni authored
Revert of [key-accumulator] Starting to reimplement the key-accumulator (patchset #14 id:260001 of https://codereview.chromium.org/1707743002/ ) Reason for revert: gcmole failure https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/8598 Original issue's description: > [key-accumulator] Starting to reimplement the key-accumulator > > Introducing the KeyAccumulator accidentally removed some crucial fast-paths. > This CL starts rewriting the KeyAccumulator, step-by-step introducing the > special cases again. > > BUG=chromium:545503, v8:4758 > LOG=y > > Committed: https://crrev.com/9c61327ecb2ee41f34232632e0cac93202bae6b7 > Cr-Commit-Position: refs/heads/master@{#34532} TBR=verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:545503, v8:4758 Review URL: https://codereview.chromium.org/1773593003 Cr-Commit-Position: refs/heads/master@{#34537}
-
cbruni authored
Introducing the KeyAccumulator accidentally removed some crucial fast-paths. This CL starts rewriting the KeyAccumulator, step-by-step introducing the special cases again. BUG=chromium:545503, v8:4758 LOG=y Review URL: https://codereview.chromium.org/1707743002 Cr-Commit-Position: refs/heads/master@{#34532}
-
- 04 Feb, 2016 1 commit
-
-
cbruni authored
BUG=v8:4724, v8:1543 LOG=N Review URL: https://codereview.chromium.org/1668853002 Cr-Commit-Position: refs/heads/master@{#33747}
-
- 25 Jan, 2016 1 commit
-
-
bmeurer authored
Cleanup %ForInPrepare runtime entry, and unify common logic with %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce a TupleType to properly type JSForInPrepare and its projections w/o special hacks in the Typer. And fix %ForInNext and JSForInNext to be consistent with fullcodegen again (after the proxy refactorings last quarter). R=jarin@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1631583002 Cr-Commit-Position: refs/heads/master@{#33487}
-
- 22 Jan, 2016 1 commit
-
-
bmeurer authored
In case the receiver map has an enum cache, %ForInPrepare returns the length of the actual enum cache, which might include properties that are further down the transition tree tho. R=jarin@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1619353002 Cr-Commit-Position: refs/heads/master@{#33469}
-
- 15 Jan, 2016 1 commit
-
-
rmcilroy authored
Adds a ForInPrepare Runtime function which returns a triple of cache_type, cache_array and cache_length. This requires adding support to CEntryStub to call runtime functions which return a ObjectTriple - a struct containing three Object* pointers. Also did some cleanup of the x64 CEntryStub to avoid replicated code. Replaces the interpreter's use of the ad-hock InterpreterForInPrepare Runtime function with ForInPrepare in preparation for fixing deopt in BytecodeGraphBuilder for ForIn (which will be done in a followup CL). MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1576093004 Cr-Commit-Position: refs/heads/master@{#33334}
-
- 27 Aug, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1306043003 Cr-Commit-Position: refs/heads/master@{#30409}
-
- 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}
-
- 08 Jun, 2015 1 commit
-
-
bmeurer authored
Both ToName() and HasProperty() can actually throw, so we need to propagate those exceptions properly. BUG=chromium:496331 LOG=y R=jarin@chromium.org Review URL: https://codereview.chromium.org/1162833006 Cr-Commit-Position: refs/heads/master@{#28829}
-
- 01 Jun, 2015 1 commit
-
-
bmeurer authored
In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a simple runtime call to ForInFilter, which does everything and is even cheaper (because FILTER_KEY used to call into the runtime anyway). And ForInFilter returns either the name or undefined, which makes it possible to remove the control flow construction from the AstGraphBuilder, and thereby make both the initialization and the per-loop code of for-in optimizable later (in typed lowering). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1160983004 Cr-Commit-Position: refs/heads/master@{#28711}
-