- 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}
-
- 22 Nov, 2016 1 commit
-
-
mstarzinger authored
This makes sure the {kScratchRegister} is not used across macro instructions (e.g. {LeaveFrame}) that would clobber its content. Generally it is highly unsafe to use such scratch registers with a life-range spanning macro instructions. R=neis@chromium.org Review-Url: https://codereview.chromium.org/2521973002 Cr-Commit-Position: refs/heads/master@{#41181}
-
- 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}
-
- 18 Nov, 2016 1 commit
-
-
bmeurer authored
Add fast paths for holey smi and object arrays to Function.prototype.apply, Reflect.apply and Reflect.construct. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2510043004 Cr-Commit-Position: refs/heads/master@{#41108}
-
- 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 2 commits
-
-
jgruber authored
BUG= Review-Url: https://codereview.chromium.org/2259883002 Cr-Commit-Position: refs/heads/master@{#38758}
-
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 2 commits
-
-
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}
-
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. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2190293003 Cr-Commit-Position: refs/heads/master@{#38364}
-
- 26 Jul, 2016 3 commits
-
-
mstarzinger authored
Reland of [interpreter] Add explicit OSR polling bytecode. (patchset #1 id:1 of https://codereview.chromium.org/2184553003/ ) Reason for revert: Fix has been landed. Original issue's description: > Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) > > Reason for revert: > Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? > > E.g.: > https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 > > Original issue's description: > > [interpreter] Add explicit OSR polling bytecode. > > > > This adds an explicit {OsrPoll} bytecode into every loop header which > > triggers on-stack replacement when armed. Note that each such bytecode > > stores the static loop depths as an operand, and hence can be armed for > > specific loop depths. > > > > This also adds builtin code that triggers OSR compilation and switches > > execution over to optimized code in case compilation succeeds. In case > > compilation fails, the bytecode dispatch just continues unhindered. > > > > R=rmcilroy@chromium.org > > TEST=mjsunit/ignition/osr-from-bytecode > > BUG=v8:4764 > > > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > > Cr-Commit-Position: refs/heads/master@{#38043} > > TBR=rmcilroy@chromium.org,mstarzinger@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:4764 > > Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc > Cr-Commit-Position: refs/heads/master@{#38044} TBR=rmcilroy@chromium.org,machenbach@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184713002 Cr-Commit-Position: refs/heads/master@{#38056}
-
machenbach authored
Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) Reason for revert: Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? E.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 Original issue's description: > [interpreter] Add explicit OSR polling bytecode. > > This adds an explicit {OsrPoll} bytecode into every loop header which > triggers on-stack replacement when armed. Note that each such bytecode > stores the static loop depths as an operand, and hence can be armed for > specific loop depths. > > This also adds builtin code that triggers OSR compilation and switches > execution over to optimized code in case compilation succeeds. In case > compilation fails, the bytecode dispatch just continues unhindered. > > R=rmcilroy@chromium.org > TEST=mjsunit/ignition/osr-from-bytecode > BUG=v8:4764 > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > Cr-Commit-Position: refs/heads/master@{#38043} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184553003 Cr-Commit-Position: refs/heads/master@{#38044}
-
mstarzinger authored
This adds an explicit {OsrPoll} bytecode into every loop header which triggers on-stack replacement when armed. Note that each such bytecode stores the static loop depths as an operand, and hence can be armed for specific loop depths. This also adds builtin code that triggers OSR compilation and switches execution over to optimized code in case compilation succeeds. In case compilation fails, the bytecode dispatch just continues unhindered. R=rmcilroy@chromium.org TEST=mjsunit/ignition/osr-from-bytecode BUG=v8:4764 Review-Url: https://codereview.chromium.org/2172233002 Cr-Commit-Position: refs/heads/master@{#38043}
-
- 21 Jul, 2016 1 commit
-
-
ahaas authored
Original message: Calling Runtime::kAbort through a builtin instead of the c-entry stub will allow to generate the call in a background thread, because a builtin provides its own handle, whereas a code stub does not. @v8-mips-ports: Could you take a special look at the padding that is done in MacroAssembler::Abort()? Reason for revert: The reason for reverting is: Blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/1622 The problem was that on arm64 the builtin for Abort() contained a call to Abort(). The problem is fixed by using a NoUseRealAbortsScope in the code generation of Abort(). R=titzer@chromium.org, rmcilroy@chromium.org, rodolph.perfetta@arm.com Review-Url: https://codereview.chromium.org/2163263002 Cr-Commit-Position: refs/heads/master@{#37929}
-