Reason for revert:
Tree closer: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/12409
Original issue's description:
> [heap] Initialize the owner on each page after lospace allocation
>
> The least two bits of the owner field of a Page are used to determine
> whether the Page is part of a large object. If these bits are not equal
> to 0x11, the page is part of a large object and needs special handling
> e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it
> belongs to.
>
> This CL fixes an issue in which the store buffer overflows after
> a large object space allocation but before the object has been fully
> initialized. Store buffer overflow handling attempts to look up the
> chunk of a page, but fails to do so correctly since the page's owner
> field has not yet been initialized.
>
> This CL ensures that the owner field of all pages belonging to a large
> object allocation are initialized to a value that is interpreted
> correctly.
>
> BUG=chromium:672041
>
> Committed: https://crrev.com/9b6808bfb5366beebe3af30a06f9851edb2039d4
> Cr-Commit-Position: refs/heads/master@{#41641}
TBR=mlippautz@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:672041
Review-Url: https://codereview.chromium.org/2562273004
Cr-Commit-Position: refs/heads/master@{#41644}
This CL moves all methods related to scripts and eval origin (HasScript,
GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase,
because it also applies to WasmFrames.
This makes the AppendFileLocation method append the same information to
WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames.
R=titzer@chromium.org, mstarzinger@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2557923005
Cr-Commit-Position: refs/heads/master@{#41642}
The least two bits of the owner field of a Page are used to determine
whether the Page is part of a large object. If these bits are not equal
to 0x11, the page is part of a large object and needs special handling
e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it
belongs to.
This CL fixes an issue in which the store buffer overflows after
a large object space allocation but before the object has been fully
initialized. Store buffer overflow handling attempts to look up the
chunk of a page, but fails to do so correctly since the page's owner
field has not yet been initialized.
This CL ensures that the owner field of all pages belonging to a large
object allocation are initialized to a value that is interpreted
correctly.
BUG=chromium:672041
Review-Url: https://codereview.chromium.org/2565713002
Cr-Commit-Position: refs/heads/master@{#41641}
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}
The evaluation order of this argument was accidentally changed when the
special-case was added for super calls with a final spread argument.
Review-Url: https://codereview.chromium.org/2563423002
Cr-Commit-Position: refs/heads/master@{#41633}
--asan test config passes --omit-quit which breaks this test on
failure.
Review-Url: https://codereview.chromium.org/2546093002
Cr-Commit-Position: refs/heads/master@{#41627}
This fixes the corner-case where the method in question failed to lookup
the very last deoptimization bailout without subsequent entries within
the relocation info. Also enable a test covering this.
R=tebbi@chromium.org
TEST=cctest/test-cpu-profiler/CollectDeoptEvents
Review-Url: https://codereview.chromium.org/2565733002
Cr-Commit-Position: refs/heads/master@{#41623}
Because the parser optimizes !123 -> false,
we allow booleans in expressions (but not parameter annotations).
Allow this in asm-wasm-builder.
Turn on an early out case in asm-typer that is fine.
BUG=672784
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2561193003
Cr-Commit-Position: refs/heads/master@{#41622}
By now the predicate in question is an exact negation of %IsAsmWasmCode
as the name intuitively implies. The need for two separate test methods
no longer exists and one of the two can be removed.
R=bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2562003002
Cr-Commit-Position: refs/heads/master@{#41616}
By now the compiler pipeline will not produce optimized code for asm.js
functions unless validation failed (even when --always-opt is enabled).
The related workaround in the testing predicate can be removed.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2549463002
Cr-Commit-Position: refs/heads/master@{#41614}
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}
The deserialization of the {Scope::asm_module} predicate relies on a
context being present for such modules. This ensures we always allocate
such a context, even in cases where no variables are allocated in it.
R=neis@chromium.org
TEST=cctest/test-parsing/AsmModuleFlag
BUG=v8:5653
Review-Url: https://codereview.chromium.org/2561103004
Cr-Commit-Position: refs/heads/master@{#41611}
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}
Fix 7a6f294ffe.
The first correction enables correct execution DoMathMinMax when two
input registers are the same register.
The second correction adds NOP instructions after branch instructions
in tests macro_float_minmaxf(32|64).
TEST=cctest/test-macro-assembler-mips[64]/macro_float_minmax_f32
cctest/test-macro-assembler-mips[64]/macro_float_minmax_f64
mjsunit/regress/math-min
BUG=
Review-Url: https://codereview.chromium.org/2556793003
Cr-Commit-Position: refs/heads/master@{#41596}
We have been assuming in several places that ContainsDot or ToInt32 is
sufficient to check a value is a valid double or int.
Refactoring all the checks to one place and making them cope with booleans
or other unexpected types being present.
BUG=672044
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2555323003
Cr-Commit-Position: refs/heads/master@{#41595}
Use of eval in a function wraps it in a context.
This throws off assumptions not checked until later,
which is at odds with incremental validation and conversion.
Check that module parameters are PARAMETER location early.
BUG=672045
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2558813004
Cr-Commit-Position: refs/heads/master@{#41594}
Wrap the liveness bitvectors from the bytecode liveness analysis with a
helper class, which makes the register/accumulator bits explicit.
Review-Url: https://codereview.chromium.org/2552723004
Cr-Commit-Position: refs/heads/master@{#41589}
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}
This CL attempts to set the maybe-assigned flag for variables that are written
to as part of a destructuring or loop header.
For instance, in the following two cases we now mark x as maybe-assigned.
a) [x] = [1];
b) for (x of [1,2,3]) {};
There's more work to do here, this is just a first step.
R=adamk@chromium.org, mstarzinger@chromium.org
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2562443003
Cr-Commit-Position: refs/heads/master@{#41582}
Currently when the number passed to TryNumberToSize is 1 << 64,
it gets away with a bug caused by rounding of mantissa.
Then the number will be casted to 0 and TryNumberToSize
will return true. This patch fix this by making the range check
more accurate.
BUG=v8:5712
Review-Url: https://codereview.chromium.org/2548243004
Cr-Commit-Position: refs/heads/master@{#41578}
-- Moves promiseHasHandlerSymbol to inobject property
-- Ports PromiseResolveClosure to TF
-- Fix a non spec async-await test which fails now because we do a map
check for native promise check (instead of IsPromise). Changing the
constructor (in the test) invalidates the map check.
This patch results in a 7.1% performance improvement in the bluebird
benchmark (over 5 runs).
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2541283002
Cr-Commit-Position: refs/heads/master@{#41569}
jasongin@ created this patch.
dcc50445a3
This patch adds the support to emit a trace event by using a comma-separated
list of categories, so that the trace event will be emitted if there is at least
one category is enabled in the categories list.
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2558193002
Cr-Commit-Position: refs/heads/master@{#41567}
Due to the isOwn check, functions inherited through prototype will not be
included in a preview.
BUG=645053
Review-Url: https://codereview.chromium.org/2554623003
Cr-Commit-Position: refs/heads/master@{#41566}
Getter properties are not currently included in the protocol's
Runtime.ObjectPreview. DevTools currently shows getter properties
when evaluating arrays in the console, and this CL brings them into
the preview generated for RemoteObjects.
Corresponding DevTools CL: https://codereview.chromium.org/2521513006/
BUG=666882
Review-Url: https://codereview.chromium.org/2508423002
Cr-Commit-Position: refs/heads/master@{#41565}
We're still collecting use counter data for this situation.
BUG=v8:4973
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2510873005
Cr-Commit-Position: refs/heads/master@{#41563}
When an octal escape sequence is in a string in strict mode:
- Octal literals are not allowed in strict mode.
+ Octal escape sequences are not allowed in strict mode.
When an octal escape sequence is in a template string:
- Octal literals are not allowed in template strings.
+ Octal escape sequences are not allowed in template strings.
BUG=v8:4973
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2551633002
Cr-Commit-Position: refs/heads/master@{#41560}
When v8 fails an access check, it invokes a helper to try to see if it
can service the request via an access check interceptor. Invoking the
access check interceptor can throw an exception (e.g. a SecurityError).
Unfortunately, the failed access check property helpers and the
interceptor helpers don't agree on how to propagate the exception: if
the interceptor helper detects a scheduled exception, it promotes the
exception to a pending exception and returns to the failed access check
property helper.
The failed access check property helper also has an early return in
case of a scheduled exception. However, this doesn't work, as the
previously thrown exception is no longer scheduled, as it's been
promoted to a pending exception. Thus, the failed access check property
helper always end up calling the failed access check callback as well.
Since Blink's implementation of the failed access check callback also
throws an exception, this conflicts with the previously-thrown,
already-pending exception.
With this patch, the failed access check property helpers check for a
pending exception rather than a scheduled exception after invoking the
interceptor, so the exception can be propagated correctly.
BUG=v8:5715
R=yangguo@chromium.org,jochen@chromium.org
Review-Url: https://codereview.chromium.org/2550423002
Cr-Commit-Position: refs/heads/master@{#41556}
Introduces:
- a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
- a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
BUG=v8:4280
R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.orgTBR=rossberg@chromium.org
Review-Url: https://codereview.chromium.org/2557593004
Cr-Commit-Position: refs/heads/master@{#41555}
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}
