... 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}
