- 15 Feb, 2016 1 commit
-
-
cbruni authored
V8 tracks already most useful information, but lacks proper tracing scopes that make it possible to distinguish certain events from each other. - add trace-scope to track lazy-parsing due to optimization - add trace-scope to track code optimization BUG= Review URL: https://codereview.chromium.org/1661883003 Cr-Commit-Position: refs/heads/master@{#34002}
-
- 09 Feb, 2016 1 commit
-
-
mstarzinger authored
The function in question can already return an empty handle in the case of failures. This makes that contract explicit by using MaybeHandle like all other compiler API functions. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1590963002 Cr-Commit-Position: refs/heads/master@{#33839}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@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/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 2 commits
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
yangguo authored
Code compiled during snapshot are overwhelmingly for functions that are only used for bootstrapping. It makes no sense to include them in the startup snapshot, which bloats up the snapshot size and slows down deserialization. Snapshot sizes for comparison, for ia32: w/o --ignition: 484k w/ --ignition: 537k bytecode removed: 489k R=rmcilroy@chromium.org,mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1667693002 Cr-Commit-Position: refs/heads/master@{#33734}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@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/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # 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/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
- 18 Jan, 2016 1 commit
-
-
mstarzinger authored
This removes the need to pass in the current unoptimized code when requesting optimized code for a function. Note that the notion of unoptimized code becomes moot when optimizing from the interpreter bytecode, hence the API should not encode such a dependency. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1588293005 Cr-Commit-Position: refs/heads/master@{#33353}
-
- 11 Jan, 2016 1 commit
-
-
sigurds authored
Escape analysis will eliminate the context, if possible. Materialization must then ensure that the materialized object has the right map, and that the context register is set accordingly. R=jarin@chromium.org BUG=569530,v8:4586 LOG=n Review URL: https://codereview.chromium.org/1572293002 Cr-Commit-Position: refs/heads/master@{#33201}
-
- 22 Dec, 2015 1 commit
-
-
bmeurer authored
These constructors always go through C++ at least twice anyway, so there's not really a point in trying to implement them in JavaScript. R=yangguo@chromium.org BUG=chromium:535408 LOG=n Review URL: https://codereview.chromium.org/1548623002 Cr-Commit-Position: refs/heads/master@{#33012}
-
- 18 Nov, 2015 1 commit
-
-
mstarzinger authored
This is to re-establish a single choke point for lazy compile stubs in preparation for CallRuntimePassFunction being changed soon. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1456003003 Cr-Commit-Position: refs/heads/master@{#32095}
-
- 12 Oct, 2015 2 commits
-
-
machenbach authored
Revert of Don't compile functions in a context the caller doesn't have access to (patchset #1 id:1 of https://codereview.chromium.org/1393713006/ ) Reason for revert: [Sheriff] Breaks layout tests. Please add needsmanualrebaseline upstream first if intended. E.g.: http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/2263 (one of them is a timeout that only happens with this commit) Original issue's description: > Don't compile functions in a context the caller doesn't have access to > > Instead, just return undefined. > > A side effect of this is that it's no longer possible to compile > functions in a detached context. > > Based on https://codereview.chromium.org/294073002 but taking access > check callbacks into account > > BUG=chromium:541703 > R=verwaest@chromium.org > LOG=y > > Committed: https://crrev.com/9a5e2f512c4aa90563eb575605c2a8c2a92ac9f4 > Cr-Commit-Position: refs/heads/master@{#31208} TBR=verwaest@chromium.org,jochen@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:541703 Review URL: https://codereview.chromium.org/1395583004 Cr-Commit-Position: refs/heads/master@{#31212}
-
jochen authored
Instead, just return undefined. A side effect of this is that it's no longer possible to compile functions in a detached context. Based on https://codereview.chromium.org/294073002 but taking access check callbacks into account BUG=chromium:541703 R=verwaest@chromium.org LOG=y Review URL: https://codereview.chromium.org/1393713006 Cr-Commit-Position: refs/heads/master@{#31208}
-
- 04 Sep, 2015 1 commit
-
-
ishell authored
BUG=chromium:527345, chromium:522289 LOG=N Review URL: https://codereview.chromium.org/1323243005 Cr-Commit-Position: refs/heads/master@{#30595}
-
- 01 Sep, 2015 1 commit
-
-
mstarzinger authored
This CL us a pure refactoring that makes an empty compilation unit including just "isolate.h" or "contexts.h" but not "objects-inl.h" compile without warnings or errors. This is needed to further reduce the header dependency tangle. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1322883002 Cr-Commit-Position: refs/heads/master@{#30500}
-
- 18 Aug, 2015 2 commits
-
-
mstarzinger authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1293053004 Cr-Commit-Position: refs/heads/master@{#30232}
-
oth authored
Bytecode generator for local assignment and basic binary operations. Command-line flag for printing bytecodes. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1294543002 Cr-Commit-Position: refs/heads/master@{#30221}
-
- 17 Aug, 2015 1 commit
-
-
jkummerow authored
Always unlink optimized code on deopt, even when FLAG_always_opt is present, because assumptions that the code made could have become invalid. BUG=v8:4375 LOG=n R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1284103006 Cr-Commit-Position: refs/heads/master@{#30196}
-
- 12 Aug, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1283183002 Cr-Commit-Position: refs/heads/master@{#30127}
-
- 24 Jul, 2015 1 commit
-
-
yangguo authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1248443003 Cr-Commit-Position: refs/heads/master@{#29840}
-
- 07 Jul, 2015 1 commit
-
-
bmeurer authored
TurboFan OSR installs the CompileOptimized builtin on JSFunctions, which means that we never evict the OSR code objects for such functions from eager deopts. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1220813018 Cr-Commit-Position: refs/heads/master@{#29507}
-
- 06 Jul, 2015 3 commits
-
-
bmeurer authored
[turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.". We have to reland these two commits at once, because the first breaks some asm.js benchmarks without the second. The change was reverted because of bogus checks in the verifier, which will not work in the presence of OSR (and where hidden because of the type back propagation hack in OSR so far). Original messages are below: [turbofan] Add new JSFrameSpecialization reducer. The JSFrameSpecialization specializes an OSR graph to the current unoptimized frame on which we will perform the on-stack replacement. This is used for asm.js functions, where we cannot reuse the OSR code object anyway because of context specialization, and so we could as well specialize to the max instead. It works by replacing all OsrValues in the graph with their values in the JavaScriptFrame. The idea is that using this trick we get better performance without doing the unsound backpropagation of types to OsrValues later. This is the first step towards fixing OSR for TurboFan. [turbofan] Perform OSR deconstruction early and remove type propagation. This way we don't have to deal with dead pre-OSR code in the graph and risk optimizing the wrong code, especially we don't make optimistic assumptions in the dead code that leaks into the OSR code (i.e. deopt guards are in dead code, but the types propagate to OSR code via the OsrValue type back propagation). BUG=v8:4273 LOG=n R=jarin@chromium.org Review URL: https://codereview.chromium.org/1226673005 Cr-Commit-Position: refs/heads/master@{#29486}
-
machenbach authored
Also revert "[turbofan] Perform OSR deconstruction early and remove type propagation." This reverts commit b0a852e8. This reverts commit cdbb6c48. NOTRY=true NOTREECHECKS=true BUG=v8:4273 LOG=n TBR=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1225743002 Cr-Commit-Position: refs/heads/master@{#29480}
-
bmeurer authored
The JSFrameSpecialization specializes an OSR graph to the current unoptimized frame on which we will perform the on-stack replacement. This is used for asm.js functions, where we cannot reuse the OSR code object anyway because of context specialization, and so we could as well specialize to the max instead. It works by replacing all OsrValues in the graph with their values in the JavaScriptFrame. The idea is that using this trick we get better performance without doing the unsound backpropagation of types to OsrValues later. This is the first step towards fixing OSR for TurboFan. R=jarin@chromium.org BUG=v8:4273 LOG=n Review URL: https://codereview.chromium.org/1225683004 Cr-Commit-Position: refs/heads/master@{#29476}
-
- 12 Jun, 2015 5 commits
-
-
wingo authored
This is a reapplication of https://codereview.chromium.org/1173333004. R=rossberg@chromium.org LOG=N BUG=498811 Review URL: https://codereview.chromium.org/1178903003 Cr-Commit-Position: refs/heads/master@{#28998}
-
wingo authored
Revert of Add script context with context-allocated "const this" (patchset #2 id:20001 of https://codereview.chromium.org/1173333004/) Reason for revert: nosnap failure Original issue's description: > Add script context with context-allocated "const this" > > This is a reapplication of https://codereview.chromium.org/1179893002/. > > R=rossberg@chromium.org,mstarzinger@chromium.org > LOG=N > BUG=498811 > > Committed: https://crrev.com/cfc764f4050edc74aef92daa4c39ccc113893968 > Cr-Commit-Position: refs/heads/master@{#28994} TBR=mstarzinger@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=498811 Review URL: https://codereview.chromium.org/1177903004 Cr-Commit-Position: refs/heads/master@{#28996}
-
wingo authored
This is a reapplication of https://codereview.chromium.org/1179893002/. R=rossberg@chromium.org,mstarzinger@chromium.org LOG=N BUG=498811 Review URL: https://codereview.chromium.org/1173333004 Cr-Commit-Position: refs/heads/master@{#28994}
-
machenbach authored
Revert of Add script context with context-allocated "const this" (patchset #7 id:120001 of https://codereview.chromium.org/1179893002/) Reason for revert: [Sheriff] Breaks gc mole: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gcmole/builds/2435 Original issue's description: > Add script context with context-allocated "const this" > > R=rossberg@chromium.org > LOG=N > BUG=498811 > > Committed: https://crrev.com/fa32d461c16a053cc6d48d3fb326016bc2765765 > Cr-Commit-Position: refs/heads/master@{#28988} TBR=rossberg@chromium.org,mstarzinger@chromium.org,wingo@igalia.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=498811 Review URL: https://codereview.chromium.org/1180043004 Cr-Commit-Position: refs/heads/master@{#28992}
-
wingo authored
R=rossberg@chromium.org LOG=N BUG=498811 Review URL: https://codereview.chromium.org/1179893002 Cr-Commit-Position: refs/heads/master@{#28988}
-
- 20 May, 2015 2 commits
-
-
mstarzinger authored
This flag mostly duplicates SharedFunctionInfo::optimization_disabled and is only queried in places where the original is available. Remove the brittle and error-prone duplication. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1148043002 Cr-Commit-Position: refs/heads/master@{#28520}
-
erikcorry authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1143133002 Cr-Commit-Position: refs/heads/master@{#28502}
-
- 21 Apr, 2015 1 commit
-
-
svenpanne authored
Baby steps towards saner #includes... Review URL: https://codereview.chromium.org/1051393003 Cr-Commit-Position: refs/heads/master@{#27958}
-
- 17 Apr, 2015 1 commit
-
-
yangguo authored
Review URL: https://codereview.chromium.org/1083083004 Cr-Commit-Position: refs/heads/master@{#27907}
-
- 16 Apr, 2015 2 commits
-
-
machenbach authored
Revert of Migrate error messages, part 2. (patchset #1 id:1 of https://codereview.chromium.org/1086313003/) Reason for revert: [Sheriff]: This changes layout test expectations e.g. http://build.chromium.org/p/client.v8/builders/V8-Blink%20Win/builds/2964 Original issue's description: > Migrate error messages, part 2. > > Motivation for this is reducing the size of the native context. > > Committed: https://crrev.com/d3b788df0a4ccfedbe6e1df5e214cb6ba2792a65 > Cr-Commit-Position: refs/heads/master@{#27878} TBR=mvstanton@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1095573002 Cr-Commit-Position: refs/heads/master@{#27889}
-
yangguo authored
Motivation for this is reducing the size of the native context. Review URL: https://codereview.chromium.org/1086313003 Cr-Commit-Position: refs/heads/master@{#27878}
-
- 14 Apr, 2015 3 commits
-
-
jochen authored
Original issue's description: > Remove support for thread-based recompilation > > BUG=v8:3608 > R=yangguo@chromium.org > LOG=y > > Committed: https://crrev.com/ed5db223a19dfe126af01 > Cr-Commit-Position: refs/heads/master@{#27619} BUG=v8:3608 R=yangguo@chromium.org LOG=y Review URL: https://codereview.chromium.org/1087763003 Cr-Commit-Position: refs/heads/master@{#27821}
-
jochen authored
Revert of Reland "Remove support for thread-based recompilation" (patchset #1 id:1 of https://codereview.chromium.org/1059853004/) Reason for revert: still times out Original issue's description: > Reland "Remove support for thread-based recompilation" > > Original issue's description: > > Remove support for thread-based recompilation > > > > BUG=v8:3608 > > R=yangguo@chromium.org > > LOG=y > > > > Committed: https://crrev.com/ed5db223a19dfe126af012e894582251aa3635d7 > > Cr-Commit-Position: refs/heads/master@{#27619} > > BUG=v8:3608 > R=yangguo@chromium.org > LOG=y > > Committed: https://crrev.com/f1ceccb8b8b352a91e6366e3e3103f1db0df6afb > Cr-Commit-Position: refs/heads/master@{#27813} TBR=yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3608 Review URL: https://codereview.chromium.org/1082183003 Cr-Commit-Position: refs/heads/master@{#27816}
-
jochen authored
Original issue's description: > Remove support for thread-based recompilation > > BUG=v8:3608 > R=yangguo@chromium.org > LOG=y > > Committed: https://crrev.com/ed5db223a19dfe126af012e894582251aa3635d7 > Cr-Commit-Position: refs/heads/master@{#27619} BUG=v8:3608 R=yangguo@chromium.org LOG=y Review URL: https://codereview.chromium.org/1059853004 Cr-Commit-Position: refs/heads/master@{#27813}
-