Move the logic into Scope::DeclareVariable to be more robust.
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2685293003
Cr-Commit-Position: refs/heads/master@{#43098}
The use of setjmp/longjmp makes the cctests in test-run-wasm and
test-run-wasm-64 flaky on Windows, and I think that it is better not
to use it. With this CL I replace it as follows:
Similar to the setjmp/longjmp implementation we still call a C
function when a trap happens. However, instead of calling longjmp in
this C function we just set a flag which indicates that a trap
happened and then return. After we return from the C function we leave
the frame of the current wasm function and return with a RET
instruction. At the end of a test the wasm test runner checks the flag
to see if a trap happened.
Please take a special look at the LeaveFrame function on arm64.
R=titzer@chromium.org, clemensh@chromium.org, v8-arm-ports@googlegroups.comCC=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2685583003
Cr-Commit-Position: refs/heads/master@{#43095}
Reason for revert:
Issue on arm64:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim/builds/5752
Original issue's description:
> [Compiler] Enable handles created during parsing and scope analysis to be deferred.
>
> In order to compile eager inner functions on a background thread we need to
> keep the handles created during parsing and scope analysis alive until the
> background compilation is complete. In order to do that, we allocate the
> handles in a deferred handle scope and keep the deferred handles alive with
> a shared_ptr in the ParseInfo and CompileInfo respectively.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2650883002
> Cr-Commit-Position: refs/heads/master@{#43091}
> Committed: 9346cd9b4cTBR=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/2687973003
Cr-Commit-Position: refs/heads/master@{#43093}
In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2650883002
Cr-Commit-Position: refs/heads/master@{#43091}
In order to allow parallel compilation of eager inner functions, we need to
seperate the zone used for parsing (which will be shared between all the
parallel compile jobs) and the zone used for compilation. This CL changes
CompilationInfo to require a zone (which can be different from the zone in
ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done
to prevent any further allocation in that zone, so that it can be shared
(read-only) with the parallel compile jobs.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2645403002
Cr-Commit-Position: refs/heads/master@{#43089}
Add a simple benchmark for a TypedArray constructor. Run once with the
default pipeline and once with turbofan so that we can compare the
performance.
Also fixes a typo in the Regex for the result of the CopyWithin
benchmark which stopped the results showing up in the perf
dashboard.
BUG=
Change-Id: Ic2eb0bd1e02b458c1163e97130abd0e7531c2e1c
Reviewed-on: https://chromium-review.googlesource.com/440225
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43087}
This CL covers only the very simple cases.
BUG=v8:5516
R=vogelheim@chromium.org
Change-Id: Ib6ddc90cbcf1c923a7b72493cfd029cfa835462b
Reviewed-on: https://chromium-review.googlesource.com/440246
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43086}
Collecting precise invocation counts need to be explicitly
enabled. Once enabled, we disable optimization (optimized
code does not increment invocation count, and may inline
callees), and make sure feedback vectors interesting for
code coverage is not garbage-collected.
R=hpayer@chromium.org, jgruber@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2686063002
Cr-Commit-Position: refs/heads/master@{#43082}
This CL includes runtime and IC parts of the tracking. It is controlled by
compile-time flag FLAG_constant_field_tracking and currently disabled.
Transition from kConst to kMutable still involves map deprecation.
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2598543003
Cr-Commit-Position: refs/heads/master@{#43081}
Collect code coverage from the available invocation counts.
The granularity is at function level, and invocation counts may
be lost to GC.
Coverage::Collect returns a std::vector of Coverage::ScriptData.
Each ScriptData contains a script ID and a std::vector of
Coverage::RangeEntry.
Each RangeEntry consists of a end position and the invocation
count. The start position is implicit from the end position of
the previous RangeEntry, or 0 if it's the first RangeEntry.
R=jgruber@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2689493002
Cr-Commit-Position: refs/heads/master@{#43072}
arguments.h is one of the headers including objects-inl.h. Files needing
objects-inl.h used to innocently pull in debug.h, so that needs to be fixed now
too.
BUG=v8:5294
R=mstarzinger@chromium.org
Change-Id: I8ce671c533ed757103ef9a3b0bf0a0509230fdd8
Reviewed-on: https://chromium-review.googlesource.com/439287
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43054}
Since the empty string is canonical HeapObject now, we can use
this fact to optimize
- strict equality comparisons with the empty string to a
simple ReferenceEqual operation, and
- optimize ToBoolean to avoid instance type checks completely.
Drive-by-fix: Allow InternalizedString for Type::HeapConstant
in the type system. This is safe, since InternalizedStrings
can be compared to other heap constants by reference (except
for non-InternalizedStrings, which are excluded from the
HeapConstant type).
BUG=v8:5267
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2681273002
Cr-Commit-Position: refs/heads/master@{#43050}
E.g.,
{ function lazy_inner(b = somevar) { let somevar; } }
If we don't produce the same scopes, PreParser thinks that the unresolved
variable inside the default parameter resolves into the variable declared inside
the function. Thus, it's not correctly recorded as a free variable.
One part is already done by https://codereview.chromium.org/2638333002 . But at
the laziness boundary, we still produced different scopes.
Unlike previously thought, this is also needed for lazy inner function
correctness, not only for "preparser scope analysis" (ie., skipping inner
functions).
BUG=v8:5938
Change-Id: I047cd43ef16478bb0f18d1f114845e7d1ab8c5f2
Reviewed-on: https://chromium-review.googlesource.com/439345
Commit-Queue: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43044}
Without doing this, a JSMessageObject can be kept alive by the isolate, which
in turn keeps the context alive, until the message is cleared.
BUG=v8:5941
Review-Url: https://codereview.chromium.org/2675203005
Cr-Commit-Position: refs/heads/master@{#43043}
Where the arguments have already been inlined, we can replace these
calls with a direct call. We have to make sure that the iteration over
the arguments is not observable.
Also factor out the large chunk of logic shared with
ReduceJSConstructWithSpread.
BUG=v8:5932
Change-Id: I6c4fac670028fbd8ca82c4474d4392231573bc49
Reviewed-on: https://chromium-review.googlesource.com/439329
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43039}
It used to require >1GB of memory which leads to flaky test failures on
machines with less memory when executing multiple variants in parallel
R=cbruni@chromium.org,ulan@chromium.org
BUG=v8:5706
Change-Id: Id8c6f49cbfa51f2d443991c1493f225810efb18f
Reviewed-on: https://chromium-review.googlesource.com/439310
Commit-Queue: Camillo Bruni <cbruni@google.com>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43038}
Arm64 compiles "x +_64 (y >> shift)" into a single instruction if
"shift" is a constant. The code generator expects that "shift" is a
32 bit constant. however, TurboFan can also pass in a 64 bit constant,
which caused a crash in the code generator.
With this CL we cast the constant of TurboFan to an int in the
instruction selector and thereby satisfy the assumption of the code
generator. This should be correct since the code generator anyways cast
the "shift" to an int5 or int6 eventually.
R=v8-arm-ports@googlegroups.com
BUG=v8:5923
Review-Url: https://codereview.chromium.org/2669203005
Cr-Commit-Position: refs/heads/master@{#43036}
Do not preinitialize the feedback vector slot if
the lookup iterator is an interceptor, because it is not
guaranteed that the iterator has a PropertyCell.
If the HandlerConfiguration has a non-masking
intercepting setter,
the iterator does not have a valid PropertyCell.
BUG=chromium:656648
Review-Url: https://codereview.chromium.org/2674103002
Cr-Commit-Position: refs/heads/master@{#43034}
The testb instruction requires the REX prefix when either of its
operands uses a register with the high bit set. The existing code only
considered the register operand. In the test case the REX prefix was not
emitted because the testb instruction had the register operand RAX which
does not have the high bit set. The REX prefix was necessary though
because the memory operand used R8, which has the high bit set.
R=bmeurer@chromium.org
BUG=chromium:688876
Change-Id: Ib214bebbe75965664f2aea530e29afa95a54f44f
Reviewed-on: https://chromium-review.googlesource.com/439145
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43030}
Previously, both type feedback vector and the shared function info
of a function points to the matching type feedback metadata. This
makes finding the shared function info of a type feedback vector
difficult.
Instead, we now point the type feeback vector to the shared function
info, and find the metadata through the shared function info.
Also remove the obsolete empty type feedback vector.
R=hpayer@chromium.org, mvstanton@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2672363002
Cr-Commit-Position: refs/heads/master@{#43026}
The AstGraphBuilder is used for asm.js only and for-in is not allowed in
valid asm.js, so we can just disable optimization for asm.js functions
that contain for-in loops. This way we only need to support for-in via
the BytecodeGraphBuilder in TurboFan now, which will make optimizations
way easier.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2679913004
Cr-Commit-Position: refs/heads/master@{#43024}
In current implementation we don't support nested scheduled break at all. If one break was scheduled inside another and second one doesn't produce actual break (execution was in blackboxed code or no JavaScript was executed) then second one will clear first scheduled break even if any not blackboxed JavaScript will be executed later.
Ambiguous break reason is added for the case when we have more then one scheduled reason. "auxData" in this case contains object with array of { reason: reason, auxData: auxData } objects for each reason in 'reasons' property.
BUG=chromium:632405
Review-Url: https://codereview.chromium.org/2678313002
Cr-Commit-Position: refs/heads/master@{#43021}
Reason for revert:
Oops, looks like the patch to change the name of $ to $262 isn't merged yet. Not sure why this didn't cause a bunch of failures--need to investigate. Reverting for now.
Original issue's description:
> test262 roll
>
> This patch changes tests right up until the SharedArrayBuffer
> tests.
>
> R=adamk
>
> Review-Url: https://codereview.chromium.org/2681833003
> Cr-Commit-Position: refs/heads/master@{#43019}
> Committed: 9588a0de5aTBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2683753003
Cr-Commit-Position: refs/heads/master@{#43020}
This patch changes tests right up until the SharedArrayBuffer
tests.
R=adamk
Review-Url: https://codereview.chromium.org/2681833003
Cr-Commit-Position: refs/heads/master@{#43019}
- removed getGeneratorObjectLocation from debugger-script.js,
- one more step to remove all debugger context usages in inspector.
BUG=v8:5510
R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org
Review-Url: https://codereview.chromium.org/2678143002
Cr-Commit-Position: refs/heads/master@{#43018}
In addition to Array.prototype.values() which is already exposed, Blink
needs access to entries(), forEach() and keys() to properly set the
corresponding functions in value iterators for WebIDL conformance.
Add a few new entries to NATIVE_CONTEXT_IMPORTED_FIELDS and expand
V8_INTRINSICS_LIST, as well as some API tests for all these new exposed
functions.
BUG=chromium:632935
R=caitp@igalia.com,jochen@chromium.org,verwaest@chromium.org,yukishiino@chromium.org
Review-Url: https://codereview.chromium.org/2670833008
Cr-Commit-Position: refs/heads/master@{#43017}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Reland: [Parse] ParseInfo owns the parsing Zone. (patchset #7 id:140001 of https://codereview.chromium.org/2632123006/ )
>
> Reason for revert:
> Speculative revert because of revert needed for https://codereview.chromium.org/2632123006
>
> Original issue's description:
> > Reland: [Parse] ParseInfo owns the parsing Zone.
> >
> > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> > in preperation for enabling background compilation jobs for inner functions
> > share the AST in the outer-function's parse zone memory (read-only), with the
> > and zone being released when all compilation jobs have completed.
> >
> > BUG=v8:5203,v8:5215
> >
> > Review-Url: https://codereview.chromium.org/2632123006
> > Cr-Original-Commit-Position: refs/heads/master@{#42993}
> > Committed: 14fb337200
> > Review-Url: https://codereview.chromium.org/2632123006
> > Cr-Commit-Position: refs/heads/master@{#42996}
> > Committed: 9e7d5a6065
>
> TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2683733002
> Cr-Commit-Position: refs/heads/master@{#43008}
> Committed: 9fe08ec067TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2679303003
Cr-Commit-Position: refs/heads/master@{#43015}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ )
>
> Reason for revert:
> Speculative revert because of https://codereview.chromium.org/2679163002/.
>
> Original issue's description:
> > [parsing] Fix maybe-assigned for loop variables.
> >
> > Due to hoisting, the value of a 'var'-declared variable may actually change even
> > if the code contains only the "initial" assignment, namely when that assignment
> > occurs inside a loop. For example:
> >
> > let i = 10;
> > do { var x = i } while (i--):
> >
> > As a simple and very conservative approximation of this, we explicitly mark
> > as maybe-assigned any non-lexical variable whose "declaration" does not
> > syntactically occur in the function scope. (In the example above, it
> > occurs in a block scope.)
> >
> > BUG=v8:5636
> >
> > Review-Url: https://codereview.chromium.org/2673403003
> > Cr-Commit-Position: refs/heads/master@{#42989}
> > Committed: a33fcd663b
>
> TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5636
>
> Review-Url: https://codereview.chromium.org/2679263002
> Cr-Commit-Position: refs/heads/master@{#43010}
> Committed: f3ae5ccf57TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2686663002
Cr-Commit-Position: refs/heads/master@{#43013}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ )
>
> Reason for revert:
> needed for properly reverting f3ae5ccf57
>
> Original issue's description:
> > Thread maybe-assigned through the bytecodes.
> >
> > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> > bytecodes, which are emitted when reading from never-assigned context slot.
> >
> > There is a subtlety here: the slot are not immutable, the meaning is
> > actually undefined-or-hole-or-immutable.
> >
> > Review-Url: https://codereview.chromium.org/2655733003
> > Cr-Commit-Position: refs/heads/master@{#43000}
> > Committed: 17c2dd3886
>
> TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Review-Url: https://codereview.chromium.org/2680923003
> Cr-Commit-Position: refs/heads/master@{#43011}
> Committed: ece4e54a31TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2679953003
Cr-Commit-Position: refs/heads/master@{#43012}
Reason for revert:
needed for properly reverting f3ae5ccf57
Original issue's description:
> Thread maybe-assigned through the bytecodes.
>
> This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> bytecodes, which are emitted when reading from never-assigned context slot.
>
> There is a subtlety here: the slot are not immutable, the meaning is
> actually undefined-or-hole-or-immutable.
>
> Review-Url: https://codereview.chromium.org/2655733003
> Cr-Commit-Position: refs/heads/master@{#43000}
> Committed: 17c2dd3886TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2680923003
Cr-Commit-Position: refs/heads/master@{#43011}
Reason for revert:
Speculative revert because of https://codereview.chromium.org/2679163002/.
Original issue's description:
> [parsing] Fix maybe-assigned for loop variables.
>
> Due to hoisting, the value of a 'var'-declared variable may actually change even
> if the code contains only the "initial" assignment, namely when that assignment
> occurs inside a loop. For example:
>
> let i = 10;
> do { var x = i } while (i--):
>
> As a simple and very conservative approximation of this, we explicitly mark
> as maybe-assigned any non-lexical variable whose "declaration" does not
> syntactically occur in the function scope. (In the example above, it
> occurs in a block scope.)
>
> BUG=v8:5636
>
> Review-Url: https://codereview.chromium.org/2673403003
> Cr-Commit-Position: refs/heads/master@{#42989}
> Committed: a33fcd663bTBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2679263002
Cr-Commit-Position: refs/heads/master@{#43010}
Reason for revert:
Speculative revert because of revert needed for https://codereview.chromium.org/2632123006
Original issue's description:
> Reland: [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Original-Commit-Position: refs/heads/master@{#42993}
> Committed: 14fb337200
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42996}
> Committed: 9e7d5a6065TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2683733002
Cr-Commit-Position: refs/heads/master@{#43008}
- Adds logical and arithmetic shifts for all integer types.
- Adds min and max for all integer types.
- Adds saturating add and subtract for small integer types.
- Removes lane operations from the MachineOperatorCache.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2668013003
Cr-Commit-Position: refs/heads/master@{#43005}
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
bytecodes, which are emitted when reading from never-assigned context slot.
There is a subtlety here: the slot are not immutable, the meaning is
actually undefined-or-hole-or-immutable.
Review-Url: https://codereview.chromium.org/2655733003
Cr-Commit-Position: refs/heads/master@{#43000}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Cleanup CHECK_EQ order and simplify CHECK_EQ(true/false).
Cleanup callorder for negative numbers
Cleanup callorder order for capital letter constants.
Cleanup callorder for test.x checks.
BUG=
Review-Url: https://codereview.chromium.org/2677183002
Cr-Commit-Position: refs/heads/master@{#42997}
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
in preperation for enabling background compilation jobs for inner functions
share the AST in the outer-function's parse zone memory (read-only), with the
and zone being released when all compilation jobs have completed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2632123006
Cr-Original-Commit-Position: refs/heads/master@{#42993}
Committed: 14fb337200
Review-Url: https://codereview.chromium.org/2632123006
Cr-Commit-Position: refs/heads/master@{#42996}
Reason for revert:
doesn't compile on ToT
Original issue's description:
> Reland: [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42993}
> Committed: 14fb337200TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2685543003
Cr-Commit-Position: refs/heads/master@{#42994}
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
in preperation for enabling background compilation jobs for inner functions
share the AST in the outer-function's parse zone memory (read-only), with the
and zone being released when all compilation jobs have completed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2632123006
Cr-Commit-Position: refs/heads/master@{#42993}
Due to hoisting, the value of a 'var'-declared variable may actually change even
if the code contains only the "initial" assignment, namely when that assignment
occurs inside a loop. For example:
let i = 10;
do { var x = i } while (i--):
As a simple and very conservative approximation of this, we explicitly mark
as maybe-assigned any non-lexical variable whose "declaration" does not
syntactically occur in the function scope. (In the example above, it
occurs in a block scope.)
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2673403003
Cr-Commit-Position: refs/heads/master@{#42989}
For x64, ia32 and x87 we would pop the return address before the stack
overflow check. This meant the stack couldn't be unwound properly if
it was going to overflow. This CL moves the pop of the return address
to after the stack overflow check.
Also adds a regression test to check that a RangeError is thrown.
BUG=689016
Review-Url: https://codereview.chromium.org/2681643004
Cr-Commit-Position: refs/heads/master@{#42984}
This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.
Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-5638
BUG=v8:5638
Review-Url: https://codereview.chromium.org/2671203003
Cr-Commit-Position: refs/heads/master@{#42981}
- entries preview available even if debugger agent is disabled,
- less deprecated mirrors usage in debugger-script.js
- no usage of debugger context - zero probability of leaking it.
- better test coverage.
BUG=v8:5510
R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org,luoe@chromium.org
Review-Url: https://codereview.chromium.org/2672213002
Cr-Commit-Position: refs/heads/master@{#42978}
- Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
- Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
relies on std::memmove rather than accessing individual eleements.
- Fixes the case where copyWithin is invoked on a TypedArray with a
detached buffer.
- Add tests to ensure that +/-Infinity (for all 3 parameters) is handled correctly by the
algorithm
The C++ version gets through the benchmark more than 25000 times as
quickly as the JS implementation.
BUG=v8:5925, v8:5929, v8:4648
R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org
Review-Url: https://codereview.chromium.org/2671233002
Cr-Commit-Position: refs/heads/master@{#42975}
Keep the order in CHECK_EQ calls consistent as
(expected, actual).
Simplify CHECK_EQ(true, expected) to CHECK(expected) and
CHECK_EQ(false, expected) to CHECK(!expected).
BUG=
Review-Url: https://codereview.chromium.org/2677133002
Cr-Commit-Position: refs/heads/master@{#42964}
The results are unreliable as-is, because es5 and es6 run in the same d8
process consecutively. The graph also shows a huge amount of noise,
which seems to be mostly resolved with this change.
Review-Url: https://codereview.chromium.org/2675263002
Cr-Commit-Position: refs/heads/master@{#42961}
In preparation for more perf work in turbofan, so that we can actually
see the results on the graph.
BUG=v8:5932
Review-Url: https://codereview.chromium.org/2676263002
Cr-Commit-Position: refs/heads/master@{#42960}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
TailCallRuntime currently does not seem to handle adaptor frames
correctly.
BUG=chromium:688690
Review-Url: https://codereview.chromium.org/2675133003
Cr-Commit-Position: refs/heads/master@{#42950}
The property details of a LookupIterator are not accessible,
if the iterator state is interceptor. Instead, use the
property attributes.
Fixes a crash in Node.js tests in Debug mode, see
c2c6ae52ea
BUG=
Review-Url: https://codereview.chromium.org/2675993002
Cr-Commit-Position: refs/heads/master@{#42941}
Blink uses access checks to be sure that objects from one context doesn't access objects in another. Heap profiler uses current context to call this checks, we need to be sure that current context is empty to allow heap profiler collect all objects without crash.
BUG=chromium:661223
R=alph@chromium.org,ulan@chromium.org
Review-Url: https://codereview.chromium.org/2669393002
Cr-Commit-Position: refs/heads/master@{#42939}
Apparently it happens quite easily that different NaNs are produced in
the interpreter than in the execution of the compiled code. This
non-determinism caused problems for the fuzzer which compares the
equality of the results of the interpreter and the compiled code.
I decided therefore to refactor the detection of non-determinism in the
interpreter. Instead of tracking whether potentially non-deterministic
NaNs were produced, I track now whether potentially non-deterministic
NaNs could have been observed. The only way the NaN non-determinism can
be observed is by observing the non-deterministic bit pattern of the
NaN. AFAICT the only way to observe the bit pattern is with a
I(32|64)_REINTERPRET_F(32|64) instruction or with a F(32|64)_STORE
followed by a load. Therefore I flag an execution as potentially
non-deterministic when either a NaN is reinterpreted to an int, or when
a NaN is stored to memory.
R=titzer@chromium.org, eholk@chromium.org
BUG=682180
Review-Url: https://codereview.chromium.org/2671803002
Cr-Commit-Position: refs/heads/master@{#42917}
The wasm module we generate for the test case actually has an initial
memory size of 16. In the mjsunit test we generate, however, we set the
initial memory size to 32. This CL changes the initial memory size in
the mjsunit test now to 16.
R=eholk@chromium.org
Change-Id: I5d3a30a97c3b0ba3105a8cf17d4c088a8fb9c8b7
Reviewed-on: https://chromium-review.googlesource.com/436544
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42915}
Turns out is_hidden is not the right condition for "scope should be present in
the preparse data". For now, replaced it with "is hidden leaf scope" (i.e.,
doesn't contain any non-hidden scopes). That's probably not the right condition
either; will be fixed once there's more data to decide what the right condition
is.
BUG=v8:5516
R=vogelheim@chromium.org
Review-Url: https://codereview.chromium.org/2669163002
Cr-Commit-Position: refs/heads/master@{#42909}
