We need it to be a PropertyCell so that we can list it as a dependency for
optimised code.
Also drive-by clean up some variable names in src/isolate-inl.h.
BUG=v8:5895
Review-Url: https://codereview.chromium.org/2658573008
Cr-Commit-Position: refs/heads/master@{#42764}
- kDebugPromiseCreated(task, parent_task)
This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.
- kDebugEnqueueAsyncFunction(task)
This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseResolve(task),
This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseReject(task),
This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.
- kDebugPromiseCollected,
This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.
- kDebugWillHandle,
This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.
- kDebugDidHandle,
This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.
With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).
Before V8Debugger supported only the following:
- asyncTaskScheduled(task1)
- asyncTaskStarted(task1)
- asyncTaskFinished(task1)
Now V8Debugger supports the following:
- asyncTaskScheduled(parent_task)
..
- asyncTaskCreated(task, parent_task),
- asyncTaskStarted(task), uses parent_task scheduled stack
- asyncTaskScheduled(task)
- asyncTaskFinished(task)
Additionally: WillHandle and DidHandle were migrated to PromiseHook API.
More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2650803003
Cr-Commit-Position: refs/heads/master@{#42644}
Instead, it is supposed to just return an empty context if it failed.
Also don't invoke interceptors (we don't for the parts that deserialize
from the snapshot anyways).
BUG=v8:5830
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2636903002
Cr-Commit-Position: refs/heads/master@{#42404}
Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2630343002
Cr-Original-Commit-Position: refs/heads/master@{#42381}
Committed: d611496b8e
Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42394}
Reason for revert:
Seems to break modules-namespace2 on gcstress.
Original issue's description:
> [Parser] Introduce AstStringConstants to share constants across AstValueFactory
>
> Creates an AstStringConstants container which pre-initializes the
> string constants used by AstValueFactory. This ensures that all
> AstValueFactories will produce the same AstValue objects for constants,
> and so they can be used by the BytecodeGenerator without having to pass
> the AstValueFactory to it, enabling construction off-thread.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2630343002
> Cr-Commit-Position: refs/heads/master@{#42381}
> Committed: d611496b8eTBR=ahaas@chromium.org,marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2638783002
Cr-Commit-Position: refs/heads/master@{#42382}
Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42381}
This changes the {MessageLocation} structure to no longer contain a
concrete {JSFunction} object but rather a {SharedFunctionInfo}. It is
much easier by now to determine, and also the concrete closure is never
actually being used.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2628973005
Cr-Commit-Position: refs/heads/master@{#42324}
Prior to this, traces recorded through chrome://tracing would not
include time spent in RunMicrotasks.
BUG=v8:5382
Review-Url: https://codereview.chromium.org/2592793003
Cr-Commit-Position: refs/heads/master@{#42316}
Before, in `var p1 = p.then(() => {}) we would trigger the
before/after callbacks with p as the associated promise, but we must
call it with p1.
Also removes promise from PromiseReactionJobInfo.
Review-Url: https://codereview.chromium.org/2633443002
Cr-Commit-Position: refs/heads/master@{#42295}
Wasm frames can be either compiled or interpreted. For interpreted wasm
frames, there is only one physical stack frame representing an
arbitrary stack of interpreted functions. Hence the physical stack
frame needs to provide a summary of the underlying functions.
Summaries were tailored for JavaScript frames before. Now they are
universal.
The refactored FrameSummaries are now also used in the FrameInspector,
and from the StackFrame objects themselves, to avoid code duplication.
All dispatch is implemented "manually", making the FrameSummary still
stack-allocatable.
BUG=v8:5822
R=yangguo@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2619353006
Cr-Commit-Position: refs/heads/master@{#42279}
and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.
R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}
... which were done after the promise has been resolved.
Goal of this CL - change promise instrumentation to support better callbacks, chained after promise resolution and prepare instrumentation for adding new asyncTaskCreated instrumentation.
Instrumentation changes:
- asyncTaskScheduled(recurring) when promise is fulfilled or rejected,
- asyncTaskCancelled when promise is collected (since [1] we can be sure that promise will survive scheduled microtasks).
Minor changes:
- async task type in inspector <-> debugger API transferred by enum instead of string,
- Debug manages async task ids based on promise objects.
More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
[1] https://codereview.chromium.org/2581503003/
BUG=chromium:632829,v8:5738
R=dgozman@chromium.org,yangguo@chromium.org,gsathya@chromium.org
Review-Url: https://codereview.chromium.org/2578923002
Cr-Commit-Position: refs/heads/master@{#42178}
-- Removes remaning debug from promise.js and moves it to c++
-- Changes debug_id to be a smi in PromiseReactionJobInfo and
PromiseResolveThenableJobInfo.
-- Changes debug_name to be a smi in PromiseReactionJobInfo and
PromiseResolveThenableJobInfo.
-- Adds PromiseDebugActionName and PromiseDebugActionType enums
-- Adds PromiseDebugActionNameToString and
PromiseDebugActionTypeToString helper methods
-- Changes variable `status` to be int in runtime functions.
-- Changes debug_id to start from 1, not 0 for easier bookkeeping.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2606093002
Cr-Commit-Position: refs/heads/master@{#42052}
This patch stores the promise, resolve, reject properties of the
deferred object created by CreateInternalPromiseCapability and
NewPromiseCapability directly on the promise (if the promise hasn't
been fulfilled), otherwise they are stored on the
PromiseReactionJobInfo.
This patch removes the currently unused
CreateInternalPromiseCapability and inlines the call to create the
deferred promise object.
NewPromiseCapability is the only function that works with a deferred.
This patch results in a 8.5% improvement in benchmarks over 5 runs.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2590563003
Cr-Commit-Position: refs/heads/master@{#41991}
The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.
While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.
R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732
Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}
When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.
R=titzer@chromium.orgCC=jgruber@chromium.org
BUG=v8:5620
Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}
This adds kInit, kResolve, kBefore and kAfter lifecycle hooks to promises.
This also exposes an API to set the PromiseHook.
BUG=v8:4643
Review-Url: https://codereview.chromium.org/2575313002
Cr-Commit-Position: refs/heads/master@{#41775}
The original patch was reverted because of performance
regressions caused by removal of old heap sizing heuristics.
This patch keeps the old heuristics and adds RAIL mode.
BUG=chromium:613518
Review-Url: https://codereview.chromium.org/2576543002
Cr-Commit-Position: refs/heads/master@{#41773}
Splits PromiseHandle into two TF builtins to account for catch
prediction. An exception in PromiseHandleReject builtin results in a
"caught" prediction whereas an expception in PromiseHandle results in a
"promise rejection" prediction.
An extra is_exception_caught bit is added to Code to mark this catch
prediction behavior.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2572623002
Cr-Commit-Position: refs/heads/master@{#41683}
The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:
test.js:17: RuntimeError: divide by zero
module.exports.main();
^
RuntimeError: divide by zero
at main (<WASM>[1]+5)
at test.js:17:16
This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:
<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
at main (<WASM>[0]+5)
at test/message/wasm-trap.js:15:16
R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110
Review-Url: https://codereview.chromium.org/2563673002
Cr-Commit-Position: refs/heads/master@{#41640}
Logging for --perf-prof is not GC safe. Now, we are going to
emit source position info for optimized code when we are
profiling, logging, or debugging, and under the same condition,
pre-compute the line ends array for line number computation.
R=tebbi@chromium.org
BUG=v8:5730
Review-Url: https://codereview.chromium.org/2562973002
Cr-Commit-Position: refs/heads/master@{#41619}
In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").
This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
table, but two (one for the call, one for the parent which does the
type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
two calls in the WASM_TO_JS wrapper (only if the module origin is
asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
which is set in ComputeCallerState. The WASM frame uses this
information to determine whether the callee frame is WASM_TO_JS, and
whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
to reconstruct the stack trace later.
R=titzer@chromium.org, bradnelson@chromium.orgCC=jgruber@chromium.org
BUG=v8:4203,v8:5724
Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}
This will be used in CSA to check if any promisehook is set.
-- Adds a is_promisehook_enabled_ field to the isolate and helper methods.
-- Adds this field to the ExternalReference table.
-- Adds a helper method to access this from CSA
Note -- this patch doesn't actually add the ability to attach the hook
yet.
BUG=v8:4643
Review-Url: https://codereview.chromium.org/2566483002
Cr-Commit-Position: refs/heads/master@{#41607}
Reason for revert:
gc-stress failures
Original issue's description:
> [wasm] Fix location for error in asm.js ToNumber conversion
>
> In the asm.js code translated to wasm, we call imported functions via a
> WASM_TO_JS stub, which first calls the function and then calls ToNumber
> on the return value. Exceptions can happen in both calls.
> We were only ever reporting the location of the function call, whereas
> asm.js code executed via turbofan reported the location of the type
> coercion operator ("+" on "+foo()" or "|" on "foo()|0").
>
> This CL implements the same behaviour for asm.js code translated to
> wasm. The following is changed:
> - the AsmWasmBuilder records the parent node when descending on a binary
> operator (also "+foo()" is represented by a binary operation).
> - it stores not one location per call in the source position side
> table, but two (one for the call, one for the parent which does the
> type coercion).
> - the wasm compiler annotates the source positions "0" and "1" to the
> two calls in the WASM_TO_JS wrapper (only if the module origin is
> asm.js).
> - during stack trace generation (in the StackTraceIterator), when we
> move from the WASM_TO_JS frame to the WASM frame, we remember at which
> call inside the WASM_TO_JS wrapper we are, and encode this information
> in the generated caller state, used for the WASM frame.
> - the same information is also stored in the FrameArray which is used
> to reconstruct the stack trace later.
>
> R=titzer@chromium.org, bradnelson@chromium.org
> CC=jgruber@chromium.org
> BUG=v8:4203,v8:5724
>
> Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
> Cr-Commit-Position: refs/heads/master@{#41599}
TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4203,v8:5724
Review-Url: https://codereview.chromium.org/2563613003
Cr-Commit-Position: refs/heads/master@{#41601}
In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").
This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
table, but two (one for the call, one for the parent which does the
type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
two calls in the WASM_TO_JS wrapper (only if the module origin is
asm.js).
- during stack trace generation (in the StackTraceIterator), when we
move from the WASM_TO_JS frame to the WASM frame, we remember at which
call inside the WASM_TO_JS wrapper we are, and encode this information
in the generated caller state, used for the WASM frame.
- the same information is also stored in the FrameArray which is used
to reconstruct the stack trace later.
R=titzer@chromium.org, bradnelson@chromium.orgCC=jgruber@chromium.org
BUG=v8:4203,v8:5724
Review-Url: https://codereview.chromium.org/2555243002
Cr-Commit-Position: refs/heads/master@{#41599}
Aside from the default snapshot, there is no need for additional context
snapshots to have the ability to replace the global proxy and global object
after deserialization. Changes include:
- Changes to the API to better distinguish default context snapshot from
additional context snapshots.
- Disallow global handles when creating snapshots.
- Allow extensions when creating snapshots.
This solves the issue of not being able to having accessors and interceptors on
the global object of contexts to be serialized.
R=jochen@chromium.org, peria@chromium.org
BUG=chromium:617892
Review-Url: https://codereview.chromium.org/2557743003
Cr-Commit-Position: refs/heads/master@{#41588}
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}
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}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/11861
See:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> Object
> -- New JSObject for promises: JSPromise
>
> Builtins
> -- PromiseThen TFJ
> -- PromiseCreateAndSet TFJ for internal use
> -- PerformPromiseThen TFJ for internal use
> -- PromiseInit for initial promise setup
> -- SpeciesConstructor for use in PromiseThen
> -- ThrowIfNotJSReceiver for use in SpeciesConstructor
> -- AppendPromiseCallback to update FixedArray with new callback
> -- InternalPerformPromiseThen
>
> Promises.js
> -- Cleanup unused symbols
> -- Remove PerformPromiseThen
> -- Remove PromiseThen
> -- Remove PromiseSet
> -- Remove PromiseAttachCallbacks
>
> Runtime
> -- PromiseSet to set promise inobject values
> -- Refactor functions to use FixedArrays for callbacks instead of
> JSArray
> -- Runtime_PromiseStatus to return promise status
> -- Runtime_PromiseResult to return promise result
> -- Runtime_PromiseDeferred to return deferred attached to promise
> -- Runtime_PromiseRejectReactions to return reject reactions attached
> to promise
>
> This CL results in a 13.07% improvement in the promises benchmark
> (over 5 runs).
>
> BUG=v8:5343
>
> Committed: https://crrev.com/30b564c76f490f8f6b311a74b25b26cf0a96be2d
> Cr-Commit-Position: refs/heads/master@{#41503}
TBR=bmeurer@chromium.org,jgruber@chromium.org,caitp@igalia.com,gsathya@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2554013002
Cr-Commit-Position: refs/heads/master@{#41512}
-- New JSObject for promises: JSPromise
Builtins
-- PromiseThen TFJ
-- PromiseCreateAndSet TFJ for internal use
-- PerformPromiseThen TFJ for internal use
-- PromiseInit for initial promise setup
-- SpeciesConstructor for use in PromiseThen
-- ThrowIfNotJSReceiver for use in SpeciesConstructor
-- AppendPromiseCallback to update FixedArray with new callback
-- InternalPerformPromiseThen
Promises.js
-- Cleanup unused symbols
-- Remove PerformPromiseThen
-- Remove PromiseThen
-- Remove PromiseSet
-- Remove PromiseAttachCallbacks
Runtime
-- PromiseSet to set promise inobject values
-- Refactor functions to use FixedArrays for callbacks instead of
JSArray
-- Runtime_PromiseStatus to return promise status
-- Runtime_PromiseResult to return promise result
-- Runtime_PromiseDeferred to return deferred attached to promise
-- Runtime_PromiseRejectReactions to return reject reactions attached
to promise
This CL results in a 13.07% improvement in the promises benchmark
(over 5 runs).
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2536463002
Cr-Commit-Position: refs/heads/master@{#41503}
This avoids the crash which ClusterFuzz found, but still does not
report the same position as without validate.asm.
For calls like "foo()|0", we report the position of the call instead of
the position of the "|" if ToNumber throws an error.
After this CL, the correctness-fuzzer for validate-asm will probably
find mismatches there.
R=titzer@chromium.org
BUG=chromium:670808
Review-Url: https://codereview.chromium.org/2548323002
Cr-Commit-Position: refs/heads/master@{#41500}
The range-based exception handler table is by now only used for bytecode
arrays. The semantics of the interpreter are that bytecode offsets point
to the beginning of the currently executing bytecode instruction. Uses
hence need to compensate for lookups based on a "retrun address". This
change removes the need for such off-by-one compensations by changing
lookup semantics to be based on "current instruction" offsets.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2534893002
Cr-Commit-Position: refs/heads/master@{#41339}
This removes support for try-catch as well as try-finally constructs
from the {FullCodeGenerator}. Consequently optimized code containing
such constructs must use the {BytecodeGraphBuilder} and can no longer
use the {AstGraphBuilder} for graph building.
R=jarin@chromium.org
BUG=v8:5657
Review-Url: https://codereview.chromium.org/2521233002
Cr-Commit-Position: refs/heads/master@{#41279}
This fixes stack unwinding to always recompute the stack pointer for
interpreted frames. For frames materialized by the deoptimizer we elide
the handler frame in between, hence arguments being pushed on the stack
will no longer be pushed into the handler frame but into the interpreted
frame directly.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-662830
BUG=chromium:662830
Review-Url: https://codereview.chromium.org/2517203003
Cr-Commit-Position: refs/heads/master@{#41170}
We don't need to check for neutered array buffers unless at least one
JSArrayBuffer has been neutered (i.e. detached in TC39 speak). For this
we introduce a protector cell that get's invalidated on first call to
the JSArrayBuffer::Neuter() method.
R=jarin@chromium.org,ulan@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2504163002
Cr-Commit-Position: refs/heads/master@{#41021}
Avoid using the iterator for arrays with fast elements where the iterator has
not been modified.
Only deals with the case where there is a single spread argument.
Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2465253011
Cr-Commit-Position: refs/heads/master@{#40998}
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
In captured stack traces, all lines and columns must be 1-based.
Even though this makes things a bit ugly, we have to comply also for
wasm locations, where line and column encode function index and byte
offset (both are originally 0-based).
If we don't comply, the frontend might complain, as e.g. DevTools does.
BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.orgCC=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2493943002
Cr-Commit-Position: refs/heads/master@{#40971}
- Creates a new promise-utils.{h, cc} which refactors out the
logic to create resolving functions. This is shared between the
runtime functions and builtins.
- Changes PromiseResolveThenableJobInfo to store the context
since we no longer create the resolving functions in JS.
- Changes EnqueuPromiseResolveThenableJob to take in the promise and
not the callbacks.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2487053002
Cr-Commit-Position: refs/heads/master@{#40941}
If an exception is thrown when there is a Promise being created, the Promise
catch prediction code would call into a part implemented in JavaScript to see if
the Promise has a catch handler. If it is not possible to call back into JS,
e.g., due to a stack overflow, then this would lead to a crash. This patch
"speculates" that, if it's impossible to call back into JavaScript, then the
error is unhandled, avoding the issue. In a future patch, the catch prediction
logic should be entirely written in C++, but this patch adds a minimal fix to
be more friendly to backports.
BUG=chromium:662935
R=jgruber
Review-Url: https://codereview.chromium.org/2487833002
Cr-Commit-Position: refs/heads/master@{#40851}
This is an experiment to check whether the heuristics is still useful.
BUG=
Review-Url: https://codereview.chromium.org/2482163002
Cr-Commit-Position: refs/heads/master@{#40833}
This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2460973003
Cr-Commit-Position: refs/heads/master@{#40745}
Reason for revert:
Static-Initializers failed on Ubuntu-12.04
Original issue's description:
> [Tracing] Use TracingCategoryObserver in runtime statistics
>
> This patch is a follow-up patch to enable runtime statistics to use
> TracingCategoryObserver.
>
> BUG=v8:5590
TBR=cbruni@chromium.org,fmeawad@chromium.org,alph@chromium.org,bmeurer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2469403005
Cr-Commit-Position: refs/heads/master@{#40743}
This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2460973003
Cr-Commit-Position: refs/heads/master@{#40742}
This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2443573002
Cr-Commit-Position: refs/heads/master@{#40617}
Reason for revert:
Causes regressions: https://bugs.chromium.org/p/chromium/issues/detail?id=658711
Original issue's description:
> [compiler] Prepare for partially shipping Ignition.
>
> This prepares the code-base so that Ignition can be enabled on a certain
> subset of compilations without setting the {FLAG_ignition} flag (which
> enables Ignition on all compilations). We should not check the flag in
> question explicitly anywhere outside of the compiler heuristics.
>
> R=mvstanton@chromium.org
BUG=chromium:658711
TBR=mvstanton@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2448443002
Cr-Commit-Position: refs/heads/master@{#40534}
This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.
R=mvstanton@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2443573002
Cr-Commit-Position: refs/heads/master@{#40507}
This enables Ignition unconditionally for all code that is destined for
optimization with TurboFan. This ensures all optimization attempts will
go through the BytecodeGraphBuilder and that the AstGraphBuilder pipe is
dried out in practice.
R=mvstanton@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2427953002
Cr-Commit-Position: refs/heads/master@{#40462}
When DevTools calls to JavaScript, it often ignores exceptions and just
fails since no value was returned.
The new --print-all-exceptions flag makes it easy to spot the location
and the reason for the thrown exception.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2417743004
Cr-Commit-Position: refs/heads/master@{#40340}
Reason for revert:
Timeout on gc stress bot.
Original issue's description:
> [heap] Cancel tasks before tearing down the heap.
>
> BUG=chromium:654343
>
> Committed: https://crrev.com/9365463d6f1fc11b2369fff63ca0ac825c61eae4
> Cr-Commit-Position: refs/heads/master@{#40272}
TBR=mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:654343
Review-Url: https://codereview.chromium.org/2414073002
Cr-Commit-Position: refs/heads/master@{#40279}
For the asm.js to WASM pipeline, the current stack traces only show
low-level WASM information.
This CL maps this back to asm.js source positions.
It does so by attaching the asm.js source Script to the compiled WASM
module, and emitting a delta-encoded table which maps from WASM byte
offsets to positions within that Script. As asm.js code does not throw
exceptions, we only store a mapping for call instructions.
The new AsmJsWasmStackFrame implementation inherits from
WasmStackFrame, but contains the logic to provide the source script and
the position inside of it.
What is still missing is the JSFunction object returned by
CallSite.getFunction(). We currently return null.
R=jgruber@chromium.org, titzer@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2404253002
Cr-Commit-Position: refs/heads/master@{#40205}
This allows us to stop using a Symbol, set as the name of the Module's
SharedFunctionInfo, as our storage for a hash.
As part of this, centralize the code for generating a random, non-zero
hash code in one place (there were previously two copies of this code,
and I needed to call it from a third file).
BUG=v8:5483
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2395233003
Cr-Commit-Position: refs/heads/master@{#40102}
This reverts commit 7db0ecdec3.
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}
Introduce AccessCompilerData which hangs off the Isolate, and initialize
it when the first PropertyAccessCompiler is instantiated. This avoids
TSAN failures when trying to access load/store calling convention arrays.
BUG=v8:5427
Review-Url: https://codereview.chromium.org/2389313002
Cr-Commit-Position: refs/heads/master@{#40055}
because ownership over it is not obviously clear
and leads to errors.
Review-Url: https://codereview.chromium.org/2366283003
Cr-Commit-Position: refs/heads/master@{#40024}
This is essentially CL/2275293002, with the difference that the effect
dependencies are now updated correctly.
BUG=
Review-Url: https://codereview.chromium.org/2378773013
Cr-Commit-Position: refs/heads/master@{#39919}
This is useful for correctness fuzzing where different compilers might
overflow the stack in different points.
Review-Url: https://codereview.chromium.org/2381773003
Cr-Commit-Position: refs/heads/master@{#39862}
Turn the StringEqualStub and friends into proper TurboFan builtins,
which means that we don't need to do on-demand compilation for those
stubs, and use those to defer lowering of the StringEqual, etc.
simplified operators to effect/control linearization (i.e. move it to
the concurrent recompilation part).
BUG=v8:5428
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2363333003
Cr-Commit-Position: refs/heads/master@{#39762}
If DevTools is turned on in the middle of doing some things with async
functions, then more items may be popped from the Promise stack than were
pushed to it. In this sort of case, it's OK to have a catch misprediction,
but a crash is unacceptable. This patch defensively handles this edge
case where the Promise stack is unexpectedly empty for that reason.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2361333003
Cr-Commit-Position: refs/heads/master@{#39705}
Reason for revert:
Regresses API see go/v8-startup-api
Original issue's description:
> [api] Clean up scopes and precheck instantiations cache
>
> Make sure all the scopes used in api-natives.cc have inlineable constructors
> and destructors. Additionally directly precheck the instantiations cache before
> trying to enter the InvokeScope which sets the save_context.
>
> BUG=chromium:630217
>
> Committed: https://crrev.com/a2496b942cad524f0f3144b107936eaa9a7c9fd5
> Cr-Commit-Position: refs/heads/master@{#38346}
TBR=yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:630217, chromium:635912
Review-Url: https://codereview.chromium.org/2366903003
Cr-Commit-Position: refs/heads/master@{#39680}
According to new store IC calling convention the value, slot and vector are passed
on the stack and there's no need in trying to preserve values or respective registers
in store handlers.
Nice bonus: we also don't need virtual registers anymore.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2357323003
Cr-Commit-Position: refs/heads/master@{#39672}
