- 03 Jan, 2017 1 commit
-
-
rmcilroy authored
Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means if the SFI has bytecode we have to go through to the runtime to install the interpreter entry trampoline into the JSFunction object. Modify the builtin to always put the SFI code object into the JSFunction unless it's the lazy compile stub on the SFI as well. BUG=v8:4380 Review-Url: https://codereview.chromium.org/2583693003 Cr-Commit-Position: refs/heads/master@{#42034}
-
- 29 Dec, 2016 1 commit
-
-
danno authored
In the process, convert from a code stub into a builtin. Review-Url: https://codereview.chromium.org/2606733002 Cr-Commit-Position: refs/heads/master@{#41986}
-
- 22 Dec, 2016 1 commit
-
-
hablich authored
Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #11 id:370001 of https://codereview.chromium.org/2504153002/ ) Reason for revert: Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/ Original issue's description: > [TypeFeedbackVector] Root literal arrays in function literals slots > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2504153002 > Cr-Commit-Position: refs/heads/master@{#41893} > Committed: https://chromium.googlesource.com/v8/v8/+/93df094081f04c629c3df2e40318de90ce5e0fb9 TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5456 Review-Url: https://codereview.chromium.org/2597163002 Cr-Commit-Position: refs/heads/master@{#41917}
-
- 21 Dec, 2016 1 commit
-
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2504153002 Cr-Commit-Position: refs/heads/master@{#41893}
-
- 08 Dec, 2016 2 commits
-
-
mvstanton authored
The patch was reverted due to a bug - we failed to evict OSR-optimized code in the case where the SharedFunctionInfo OptimizedCodeMap was empty/cleared. Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. Review-Url: https://codereview.chromium.org/2561083002 Cr-Commit-Position: refs/heads/master@{#41584}
-
bmeurer authored
Revert of Store OSR'd optimized code on the native context. (patchset #8 id:140001 of https://codereview.chromium.org/2549753002/ ) Reason for revert: Speculative revert WebGL breakage reported in https://bugs.chromium.org/p/chromium/issues/detail?id=672367 Original issue's description: > Store OSR'd optimized code on the native context. > > Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. > > BUG= > > Committed: https://crrev.com/378b6b22fb7925ac5b672335a54599f5739e7758 > Cr-Commit-Position: refs/heads/master@{#41554} TBR=mstarzinger@chromium.org, mvstanton@chromium.org, ulan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2562623003 Cr-Commit-Position: refs/heads/master@{#41571}
-
- 07 Dec, 2016 1 commit
-
-
mvstanton authored
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. BUG= Review-Url: https://codereview.chromium.org/2549753002 Cr-Commit-Position: refs/heads/master@{#41554}
-
- 29 Nov, 2016 2 commits
-
-
rmcilroy authored
Adds a bytecode_age field to BytecodeArray objects. This is incremented each time the bytecode array is marked by GC, and reset to zero if the bytecode is executed. This is used to enable the CompilationCache for interpreted functions, where Interpreted entries are evicted once the bytecode becomes old. BUG=chromium:666275,v8:4680 Review-Url: https://codereview.chromium.org/2534763003 Cr-Commit-Position: refs/heads/master@{#41356}
-
rmcilroy authored
MarkingParity was used to avoid performing an operation on an object if it was marked multiple times. We no longer mark things multiple times, so this concept is no longer required. BUG=chromium:666275 Review-Url: https://codereview.chromium.org/2529173002 Cr-Commit-Position: refs/heads/master@{#41354}
-
- 28 Nov, 2016 1 commit
-
-
rodolph.perfetta authored
BUG= Review-Url: https://codereview.chromium.org/2537453003 Cr-Commit-Position: refs/heads/master@{#41325}
-
- 21 Nov, 2016 1 commit
-
-
mstarzinger authored
This removes the deprecated generator support for resumable functions from {FullCodeGenerator}. The existing {AstNumbering} heuristic already triggers Ignition for most resumable functions, with this change we make said heuristic a hard choice and remove the deprecated code. This also has the advantage that any suspended {JSGeneratorObject} instance on the heap is guaranteed to have code based on a bytecode array. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2504223002 Cr-Commit-Position: refs/heads/master@{#41135}
-
- 11 Nov, 2016 3 commits
-
-
leszeks authored
Fixes incorrect checks for handle validity when checking the compiled code, as well as incorrect uses of tst in arm and ppc flag checking code. Also adds a test that the tier-up works correctly. Reland of https://codereview.chromium.org/2448933002 BUG=v8:5512 Review-Url: https://codereview.chromium.org/2497573003 Cr-Commit-Position: refs/heads/master@{#40930}
-
bmeurer authored
Revert of [compiler] Fix flipped boolean checks in marked tier-up (patchset #7 id:120001 of https://codereview.chromium.org/2478323002/ ) Reason for revert: Breaks deopt fuzzer: https://build.chromium.org/p/client.v8/builders/V8%20Deopt%20Fuzzer/builds/14872/steps/Deopt%20Fuzz%20on%20Ubuntu-12.04/logs/stdio Original issue's description: > [compiler] Fix flipped boolean checks in marked tier-up > > Fixes incorrect checks for handle validity when checking the compiled > code, as well as incorrect uses of tst in arm and ppc flag checking > code. Also adds a test that the tier-up works correctly. TBR=rmcilroy@chromium.org,leszeks@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2492523007 Cr-Commit-Position: refs/heads/master@{#40919}
-
leszeks authored
Fixes incorrect checks for handle validity when checking the compiled code, as well as incorrect uses of tst in arm and ppc flag checking code. Also adds a test that the tier-up works correctly. Review-Url: https://codereview.chromium.org/2478323002 Cr-Commit-Position: refs/heads/master@{#40915}
-
- 10 Nov, 2016 1 commit
-
-
mstarzinger authored
This changes {FrameState} nodes modeling "after" states to use bytecode offsets pointing to the deoptimizing bytecode. This is in sync with the normal execution, as the bytecode offset is advanced after operations complete in regular bytecode handlers. The change is necessary to ensure lazy deoptimized frames contain an accurate bytecode offset while they are on the stack. Such frames can be inspected by various stack walks. The continuation builtin will advance the bytecode offset upon return. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-660379 BUG=chromium:660379 Review-Url: https://codereview.chromium.org/2487173002 Cr-Commit-Position: refs/heads/master@{#40887}
-
- 04 Nov, 2016 1 commit
-
-
mstarzinger authored
This removes the deprecated flag in question which has been enabled by default a while ago. All components can by now deal with activations of a single function being mixed between Ignition and other compilers. The maintenance overhead to support a mode that clears bytecode is no longer warranted. R=rmcilroy@chromium.org BUG=v8:4280 Review-Url: https://codereview.chromium.org/2475203003 Cr-Commit-Position: refs/heads/master@{#40776}
-
- 27 Oct, 2016 1 commit
-
-
leszeks authored
Reuses (and renames) the SFI "mark for optimization" flag to also permit marking for baseline recompilation. The flag now represents a "tier up" request, and CompileLazy can get baseline code as well as optimized code. BUG=v8:5512 Review-Url: https://codereview.chromium.org/2448933002 Cr-Commit-Position: refs/heads/master@{#40612}
-
- 21 Oct, 2016 1 commit
-
-
leszeks authored
The current method of marking functions for optimization, which replaces the JSFunction's code object with one that triggers optimization, would never allow unnamed functions to be optimized. This is an issue for a style of programming which heavily relies on passing around closures. This patch sets a bit on the SharedFunctionInfo when a JSFunction is marked. When another JSFunction referring to the same SharedFunctionInfo is lazily compiled, it immediately triggers a non-concurrent optimize. BUG=v8:5512 Review-Url: https://chromiumcodereview.appspot.com/2437043002 Cr-Commit-Position: refs/heads/master@{#40506}
-
- 18 Oct, 2016 1 commit
-
-
bmeurer authored
This slot is completely unused and always undefined anyways, so there's no need to maintain the slot during object construction. R=yangguo@chromium.org BUG=v8:5049 Review-Url: https://codereview.chromium.org/2423323002 Cr-Commit-Position: refs/heads/master@{#40377}
-
- 07 Oct, 2016 6 commits
-
-
jgruber authored
BUG= Committed: https://crrev.com/7db0ecdec3cf330766575cb7973b983f3f1e3020 Review-Url: https://codereview.chromium.org/2381843002 Cr-Original-Commit-Position: refs/heads/master@{#40080} Cr-Commit-Position: refs/heads/master@{#40087}
-
Mike Stanton authored
(GcStress failure was unrelated.) At one time, we hoped to generate the same code for different native contexts. But in truth, much performance comes from optimizing on the native context. Now we abandon this pathway. BUG= TBR=bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true Review URL: https://codereview.chromium.org/2402663002 . Cr-Commit-Position: refs/heads/master@{#40086}
-
jgruber authored
This reverts commit 7db0ecde. Manual revert since automatic revert is too large for the web interface. BUG= TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,ahaas@chromium.org NOPRESUBMIT=true NOTREECHECKS=true Review-Url: https://codereview.chromium.org/2396353002 Cr-Commit-Position: refs/heads/master@{#40082}
-
mvstanton authored
Revert of [turbofan] Discard the shared code entry in the optimized code map. (patchset #3 id:40001 of https://codereview.chromium.org/2401653002/ ) Reason for revert: Possible GCSTRESS failure, investigating. Original issue's description: > [turbofan] Discard the shared code entry in the optimized code map. > > At one time, we hoped to generate the same code for different > native contexts. But in truth, much performance comes from optimizing > on the native context. Now we abandon this pathway. > > BUG= > > Committed: https://crrev.com/55af3c44c99a6e4cd6d53df775023d760ad2b2c3 > Cr-Commit-Position: refs/heads/master@{#40079} TBR=mstarzinger@chromium.org,ishell@chromium.org,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/2403453002 Cr-Commit-Position: refs/heads/master@{#40081}
-
jgruber authored
BUG= Review-Url: https://codereview.chromium.org/2381843002 Cr-Commit-Position: refs/heads/master@{#40080}
-
mvstanton authored
At one time, we hoped to generate the same code for different native contexts. But in truth, much performance comes from optimizing on the native context. Now we abandon this pathway. BUG= Review-Url: https://codereview.chromium.org/2401653002 Cr-Commit-Position: refs/heads/master@{#40079}
-
- 06 Oct, 2016 1 commit
-
-
tebbi authored
BUG=v8:5431 Review-Url: https://codereview.chromium.org/2372113004 Cr-Commit-Position: refs/heads/master@{#40051}
-
- 29 Sep, 2016 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2380973002 Cr-Commit-Position: refs/heads/master@{#39872}
-
- 16 Sep, 2016 1 commit
-
-
mythria authored
In ignition, arguments to function calls and function constructors are pushed onto the stack before calling the function. It is required to check that stack does not overflow when pushing the arguments. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2335513004 Cr-Commit-Position: refs/heads/master@{#39470}
-
- 15 Sep, 2016 1 commit
-
-
Alexander.Gilday2 authored
Migrate the platform DatePrototype_GetField (and all wrappers) to TurboFan. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2263533002 Cr-Commit-Position: refs/heads/master@{#39438}
-
- 14 Sep, 2016 1 commit
-
-
bmeurer authored
Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
-
- 12 Sep, 2016 1 commit
-
-
Alexander.Gilday2 authored
Migrate ToNumber platform builtin to TurboFan. Also move NonNumberToNumber builtin implementation to helper function. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2327703003 Cr-Commit-Position: refs/heads/master@{#39343}
-
- 08 Sep, 2016 1 commit
-
-
mythria authored
Adds support to collect allocation site feedback for Array function calls to the call bytecode handler. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2307903002 Cr-Commit-Position: refs/heads/master@{#39283}
-
- 02 Sep, 2016 1 commit
-
-
mythria authored
Collect type feedback in the bytecode handler for 'new' bytecode. The earlier cl (https://codereview.chromium.org/2153433002/) was reverted because that implementation did not collect allocation site feedback. This regressed delta blue by an order of magnitude. This implementation includes collection of allocation site feedback. Reland of https://codereview.chromium.org/2190293003/ with a bug fix. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2225923003 Cr-Commit-Position: refs/heads/master@{#39120}
-
- 30 Aug, 2016 1 commit
-
-
jgruber authored
This was exposed on win64 and manifested as a negative offset during stack frame collection, i.e. pc < Code::instruction_start() for a BUILTIN frame. This happened because StackFrame::LookupCode returns the wrong code object when call is the last instruction in a code object: * pc is actually the return address for all but the topmost frame. * pc points at the next instruction after the call. * This is beyond the current code object if call is the last instruction. * Lookup itself is naive in that it just returns the first code object for which (next_code_obj_addr > pc). It does not check that pc is actually within [instruction_start, instruction_end[. * In this specific case, the pc (== return address) actually pointed at the beginning of the header of the next code object. * We finally calculated offset as (code->instruction_start() - pc), but with the wrong code object. This should be followed up by a proper fix at some point. For instance, this could be setting pc to (return address - 1) for all but the topmost frame. BUG=v8:5311 Review-Url: https://codereview.chromium.org/2284673002 Cr-Commit-Position: refs/heads/master@{#38996}
-
- 19 Aug, 2016 1 commit
-
-
mstarzinger authored
This fixes the self-healing mechanism for closures in the interpreter entry trampoline not that bytecode can be preserved even when baseline code is already available. R=rmcilroy@chromium.org TEST=cctest/test-compiler/IgnitionEntryTrampolineSelfHealing BUG=chromium:638225 Review-Url: https://codereview.chromium.org/2257143002 Cr-Commit-Position: refs/heads/master@{#38747}
-
- 17 Aug, 2016 1 commit
-
-
bradnelson authored
Our previous per-arch instantiation thunks for asm.js didn't support modules that had or were called with anything other than 3 arguments. Adding support for this. Addding a runtime test method to check if asm validation succeeded. Adding a test of validation with different argument count combinations. R=mstarzinger@chromium.org TEST=mjsunit/asm/asm-validator.js BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203 Review-Url: https://codereview.chromium.org/2229723002 Cr-Commit-Position: refs/heads/master@{#38688}
-
- 12 Aug, 2016 1 commit
-
-
yangguo authored
Previously, we would both instrument the code, and add/remove BreakPointInfo objects through BreakLocation. This is bad design and unsuitable for having two different code kinds. We would now add/remove BreakPointInfo objects, and use that as source of truth when instrumenting the code. If we have both bytecode and FCG code, we would simply apply these break points twice to either. Notable changes: - Removed many functionality from BreakLocation. - Instrumentation (patching code for breaks) happens by applying break point info onto code. - Instrumentation (code patching) is done by the BreakIterator. For bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's CodeBreakIterator. - Changes to code instrumentation mostly involves clearing current instrumentation and then (re-)applying break points. - DebugInfo can now reference both bytecode and FCG code. R=jgruber@chromium.org, mstarzinger@chromium.org BUG=v8:5265 Review-Url: https://codereview.chromium.org/2238893002 Cr-Commit-Position: refs/heads/master@{#38596}
-
- 11 Aug, 2016 1 commit
-
-
Alexander.Gilday2 authored
Migrate the platform StringToNumber builtin to TurboFan. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2235983003 Cr-Commit-Position: refs/heads/master@{#38573}
-
- 09 Aug, 2016 1 commit
-
-
franzih authored
Drive-by fix: Use CodeStubAssembler::LoadNativeContext() BUG=chromium:608675 Review-Url: https://codereview.chromium.org/2227763003 Cr-Commit-Position: refs/heads/master@{#38501}
-
- 05 Aug, 2016 1 commit
-
-
machenbach authored
Revert of [Interpreter] Collect type feedback for 'new' in the bytecode handler (patchset #6 id:100001 of https://codereview.chromium.org/2190293003/ ) Reason for revert: [Sheriff] Fails on nosnap debug: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/8403 Original issue's description: > [Interpreter] Collect type feedback for 'new' in the bytecode handler > > Collect type feedback in the bytecode handler for 'new' bytecode. The > earlier cl (https://codereview.chromium.org/2153433002/) was reverted > because that implementation did not collect allocation site feedback. > This regressed delta blue by an order of magnitude. This implementation > includes collection of allocation site feedback. > > BUG=v8:4280, v8:4780 > LOG=N > > Committed: https://crrev.com/9d5e6129c4c7f9cbfe81a5fad2a470f219fe137c > Cr-Commit-Position: refs/heads/master@{#38364} TBR=bmeurer@chromium.org,rmcilroy@chromium.org,balazs.kilvady@imgtec.com,mythria@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280, v8:4780 Review-Url: https://codereview.chromium.org/2212343002 Cr-Commit-Position: refs/heads/master@{#38368}
-