Also add more local variables to regress-v8-6077 to force
register spill on platform with 32 float registers.
BUG=
Review-Url: https://codereview.chromium.org/2822073003
Cr-Commit-Position: refs/heads/master@{#44865}
This reverts commit 56a6fda316.
Reason for revert: Makes tsan flaky:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/15038
Original change's description:
> [parser] Inital parallel parse tasks implementation.
>
> While parsing top-level code eager functions are skipped just like lazy
> ones, but also a parse task is created for each.
>
> The parse tasks are run by the compiler dispatcher and can be executed
> either on background thread or in idle time.
> After parsing of top-level code finishes it waits for all unfinished
> parser tasks - possibly picking up and executing them on current thread.
> Afterwards parse task results are stitched together with top-level AST,
> in case of failures eager functions are treated just like lazy -
> parsing/compilation is retriggered for them in the runtime and proper
> errors are generated (performance is not optimized for error case at
> all).
>
> BUG=v8:6093
>
> Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
> Reviewed-on: https://chromium-review.googlesource.com/483439
> Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44849}
TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6093
Change-Id: I17e689efee7d216d28a94a5c8147022ae7e830dd
Reviewed-on: https://chromium-review.googlesource.com/486883
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44859}
With this CL SloppyArguments immediately go to dictionary elements on
deletion, keeping the arguments backing store packed.
Bug: v8:6251
Change-Id: I2afa4fb5f0af9942eee0a1606942f5f289539330
Reviewed-on: https://chromium-review.googlesource.com/480379
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44857}
This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.
Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.
Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.
This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}
This fixes propagation of validation failures that happen during the
validation of a heap access expression in {ValidateHeapAccess}.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-714971
BUG=chromium:714971
Change-Id: I8f91ac1da34ae50fdde2938f61b6468cdac92b6e
Reviewed-on: https://chromium-review.googlesource.com/486801
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44851}
While parsing top-level code eager functions are skipped just like lazy
ones, but also a parse task is created for each.
The parse tasks are run by the compiler dispatcher and can be executed
either on background thread or in idle time.
After parsing of top-level code finishes it waits for all unfinished
parser tasks - possibly picking up and executing them on current thread.
Afterwards parse task results are stitched together with top-level AST,
in case of failures eager functions are treated just like lazy -
parsing/compilation is retriggered for them in the runtime and proper
errors are generated (performance is not optimized for error case at
all).
BUG=v8:6093
Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
Reviewed-on: https://chromium-review.googlesource.com/483439
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44849}
This header file is only used from tests.
Also, move the LoadStoreOpcodeOf method (only used in tests) from
wasm-opcodes.h to wasm-macro-gen.h.
R=ahaas@chromium.org
Change-Id: I8d4691be494b5c1fbe3084441329850930bad647
Reviewed-on: https://chromium-review.googlesource.com/486861
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44845}
Adds a micro benchmark in js-perf-test to measure the performance of
compare bytecode handlers.
Bug:v8:4280
Change-Id: Ic86d670f8f09147076a22cfeff2e1ec052afe20c
Reviewed-on: https://chromium-review.googlesource.com/485522
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44843}
Instead of using the WASM_I32V_* macros (and other) from
wasm-macro-gen.h, use the appropriate methods to encode LEB integers.
This also saves some spaces for the wasm bytecode generated from asm.js.
Specifically, this CL
1) renames EmitVarInt to EmitI32V and EmitVarUint to EmitU32V (on
WasmFunctionBuilder).
2) introduces more methods on the WasmFunctionBuilder to emit i64v,
u64v, f32, and f64 values.
3) uses the ZoneBuffer instead of a plain ZoneVector<char> in the
WasmFunctionBuilder to build the body of the function.
4) introduces more helper functions on the ZoneBuffer to encode i64v,
u64v, f32 and f64 values.
R=ahaas@chromium.org
Change-Id: Ifa59a6a67380ecf9a3823c382daf00855f5bc61e
Reviewed-on: https://chromium-review.googlesource.com/486803
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44842}
Some of these tests pass the pattern as a string, and in this case
there's a subtle distinction between
"/\u{0041}/" // Unicode escape interpreted in string literal.
and
"/\\u{0041}/" // Unicode escape interpreted by regexp parser.
Extend these tests to check both cases.
Thanks littledan@ for pointing this out.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2839923002
Cr-Commit-Position: refs/heads/master@{#44840}
wasm-macro-gen.h is mainly used from tests, but LocalDeclEncoder is
also used from various other places.
This CL moves the LocalDeclEncoder to an own compilation unit. We want
to later move wasm-macro-gen.h to the tests folder.
It also refactors the LocalDeclEncoder to reuse the
LEBHelper::write_u32v and LEBHelper::sizeof_u32v methods instead of
reimplementing it.
R=ahaas@chromium.org
Change-Id: Ia4651436f0544578da7c1c43596d343571942e97
Reviewed-on: https://chromium-review.googlesource.com/486724
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44838}
Instead of dynamically tracking the block nesting, precompute the
information statically.
The interpreter was already using a side table to store the pc diff for
each break, conditional break and others. The information needed to
adjust the stack was tracked dynamically, however. This CL also
precomputes this information, as it is statically known.
Instead of just storing the pc diff in the side table, we now store the
pc diff, the stack height diff and the arity of the target block.
Local measurements show speedups of 5-6% on average, sometimes >10%.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I986cfa989aabe1488f2ff79ddbfbb28aeffe1452
Reviewed-on: https://chromium-review.googlesource.com/485482
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44837}
I think the WebAssembly format changed since the last time we updated
the corpus.
R=bradnelson@chromium.org
Change-Id: Ic4e24bade8cffbd43025d0961b805757a5e6f4d6
Reviewed-on: https://chromium-review.googlesource.com/485801
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44832}
VC++ 2017's STL doesn't suppress warnings as aggressively as prior
versions did. This causes warnings on code which mixes signed and
unsigned types. In this case a deque of unsigned integers was being
queried to see how many signed integers it contains. This could be
fixed by passing in unsigned 0, 1, and 2 to std::count but changing
the deque from unsigned to int is simpler.
R=adamk@chromium.org
BUG=chromium:683729
Review-Url: https://codereview.chromium.org/2834293002
Cr-Commit-Position: refs/heads/master@{#44814}
This makes it easier to set the value for embedders where it is
difficult to plumb through to the Isolate constructor.
BUG=chromium:711809
R=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2829223002
Cr-Commit-Position: refs/heads/master@{#44813}
- Adds new F32x4AddHoriz, I32x4AddHoriz, etc. to WASM opcodes.
- Implements them for ARM.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2804883008
Cr-Commit-Position: refs/heads/master@{#44812}
In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.
This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.
TBR=bmeurer@chromium.org (just adding a comment)
Previously reviewed at https://codereview.chromium.org/2830093002
Previously landed as 98acfb36e1 / r44799
Review-Url: https://codereview.chromium.org/2840583002
Cr-Commit-Position: refs/heads/master@{#44808}
I have no idea how the empty folder got
in there in the first place ¯\_(ツ)_/¯.
Bug:
Change-Id: I0fd94d1dec76f2444b24f772c1691924f872ec55
Reviewed-on: https://chromium-review.googlesource.com/485621
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44803}
- Split out code for Intl objects into src/objects/
- Rename i18n to intl (except for the name of the build flag)
- Use build system more broadly to turn on/off Intl code
- Delete a little bit of dead code
Bug: v8:5751
Change-Id: I41bf2825a5cb0df20824922b17c24cae637984da
Reviewed-on: https://chromium-review.googlesource.com/481284
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44801}
This makes sure that typed array constructors (e.g. Int8Array, ...) used
within an asm.js module are considered uses of stdlib values, and hence
are checked during module instantiation.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6280
BUG=v8:6280,chromium:714537
Change-Id: Ic5d689f5319c4dac4e9df3dca4a8cf5a4edd890b
Reviewed-on: https://chromium-review.googlesource.com/485521
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44800}
In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.
This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.
TBR=bmeurer@chromium.org (just adding a comment)
Review-Url: https://codereview.chromium.org/2830093002
Cr-Commit-Position: refs/heads/master@{#44799}
Add missing kEnd opcode after each body. Also, avoid the macro.
This fix is needed for follow-up changes to the control transfer
computation.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If2b4dbea831ec40939a2045701f3d13479331773
Reviewed-on: https://chromium-review.googlesource.com/485481
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44794}
For now skip some WASM SIMD tests that fail when MIPS SIMD extension is
not available. Turn on these tests again when simd scalar lowering
mechanism supports all WASM SIMD operations.
BUG=
Review-Url: https://codereview.chromium.org/2829963003
Cr-Commit-Position: refs/heads/master@{#44791}
Consistently support calls to host-C-linkage functions with up to 9 arguments
from the simulator, and check that these limits aren't exceeded accidentally.
BUG=v8:6281
Review-Url: https://codereview.chromium.org/2825393003
Cr-Commit-Position: refs/heads/master@{#44790}
We already have an optimization to constant-fold access to an object's
prototype via the special __proto__ accessor (specified in appendix B).
We can use the same optimization to also constant-fold accesses to an
object's prototype via the official Object.getPrototypeOf function.
Also add the optimization for Reflect.getPrototypeOf, which is
equivalent for object inputs.
This is commonly used by Babel to implement various new language
features, for example subclassing and certain property lookups.
R=yangguo@chromium.org
BUG=v8:6292
Review-Url: https://codereview.chromium.org/2841463002
Cr-Commit-Position: refs/heads/master@{#44788}
.. replace all of them with prepared global object template.
+ bonus: wrap inspector related methods with inspector namespace.
BUG=none
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2832723004
Cr-Commit-Position: refs/heads/master@{#44785}
These can be synthesized from existing operations and scheduled for
better performance than if we have to generate blocks of instructions
that take many cycles to complete.
- Remove F32x4RecipRefine, F32x4RecipSqrtRefine. Clients are better off
synthesizing these from splats, multiplies and adds.
- Remove F32x4Div, F32x4Sqrt, F32x4MinNum, F32x4MaxNum. Clients are
better off synthesizing these or using the reciprocal approximations,
possibly with a refinement step.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2827143002
Cr-Commit-Position: refs/heads/master@{#44784}
Ensure source map is not stable if elements kind transitions are expected.
BUG=chromium:700733
Change-Id: Ie937e7064127250b1100109986c3e9b411fae1d6
Reviewed-on: https://chromium-review.googlesource.com/483442
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44780}
This also removes a broken optimization regarding immutable (i.e. const)
global variables. For now mutable and immutable global variables are
treated the same and hence copied during module initialization.
R=rossberg@chromium.org
TEST=mjsunit/asm/global-imports
BUG=v8:6279
Change-Id: I020fc12036dc534f5a62fb43f5c6fdb252314e62
Reviewed-on: https://chromium-review.googlesource.com/483360
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44763}
The included test case illustrates the problem. It subtracts (16 << 27)
from another number. The Machine Operator Reducer would replace the
shift computation with 0x0000000080000000, and then change the subtract
to an add of -(0x0000000080000000), which is 0xffffffff80000000.
The instruction selector would determine that this value could be an
immediate, because it fits in 32 bits, so it would select the lea
instruction. Finally, the code generator would detect that the
immediate was less than 0, flip the sign and replace the add with a
subtract of 0x80000000. Because the x64 subtract instruction's
immediate field is 32 bits, the processor would interpret this as
0xffffffff80000000 instead of an unsigned value.
This change fixes the issue by making the CanBeImmediate check
explicitly compare against INT_MIN and INT_MAX. We disallow INT_MIN
as an immediate precisely because we cannot tell 0x0000000080000000
from 0xffffffff80000000 when truncated to 32 bits.
Bug: chromium:711203
Change-Id: Ie371b8ea290684a6bb723bae9c693a866f961850
Reviewed-on: https://chromium-review.googlesource.com/482448
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44758}
With recent CLs we always store maximum N async stack traces and when we reach limit we drop half of them.
Current promise collected event requires creating weak handle:
- it takes time,
- it consumes memory.
Since async task id distribution for promises is uniform (each new promise has last_async_task_id + 1 as an id) our hash map is good enough to handle any amount of async task ids, following time of executing 1 000 000 000 of lookups:
- for empty hash map: 1.45 seconds,
- for hash map with one entry: 14.95 seconds
- 1024 entries: 15.03 seconds
- 1024 * 1024 entries: 14.82 seconds
- 1024 * 1024 * 1024: 17.9 seconds
BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2819423005
Cr-Commit-Position: refs/heads/master@{#44750}
For MIPS64, many load/store operations from/to memory emit more then
one instruction. This is the reason for moving them from assembler to
macro-assembler.
TEST=
BUG=
Review-Url: https://codereview.chromium.org/2829073002
Cr-Commit-Position: refs/heads/master@{#44746}
So that we can delete object properties without a runtime call.
The builtin implements a few fast paths (for now only deletion
of dictionary properties), and calls the runtime for all other
cases.
Review-Url: https://codereview.chromium.org/2810363003
Cr-Commit-Position: refs/heads/master@{#44740}
- Adds unary Reverse shuffles (swizzles): S32x2Reverse, S16x4Reverse,
S16x2Reverse, S8x8Reverse, S8x4Reverse, S8x2Reverse. Reversals are
done within the sub-vectors that prefix the opcode name, e.g. S8x2
reverses the 8 consecutive pairs in an S8x16 vector.
- Adds binary Zip (interleave) left and right half-shuffles to return a
single vector: S32x4ZipLeft, S32x4ZipRightS16x8ZipLeft, S16x8ZipRight,
S8x16ZipLeft, S8x16ZipRight.
- Adds binary Unzip (de-interleave) left and right half shuffles to return
a single vector: S32x4UnzipLeft, S32x4UnzipRight, S16x8UnzipLeft,
S16x8UnzipRight, S8x16UnzipLeft, S8x16UnzipRight.
- Adds binary Transpose left and right half shuffles to return
a single vector: S32x4TransposeLeft, S32x4TransposeRight,
S16x8TransposeLeft, S16xTransposeRight, S8x16TransposeLeft,
S8x16TransposeRight.
- Adds binary Concat (concatenate) byte shuffle: S8x16Concat #bytes to
paste two vectors together.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2801183002
Cr-Commit-Position: refs/heads/master@{#44734}
There's no reason to keep track, for a preparsed function itself,
whether that function calls eval. All that matters is that the ancestor
scopes are marked as having an inner scope which calls eval. The function
will have its "calls eval" bit persisted if/when it's fully parsed.
The only "behavioral" change in this patch is the removal of a DCHECK.
Bug: v8:6092
Change-Id: I17e396c8a265030fe0ad941707e4a97972e6650b
Reviewed-on: https://chromium-review.googlesource.com/481223
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44732}
let/const declarations in "standard" C-style for-loops have
some complex desugaring to accommodate the case where loop
loop variables may be captured. This slows down the baseline
performance of for-loops with let variables.
This change attempts to avoid this desugaring if it's known that
the loop variable is not captured at any point. A side effect of
this change is that let/const loop variables, when not captured
within the loop body, are not necessarily shown in the debugger,
similar to other stack-allocated vars.
BUG=v8:4762, v8:5460
R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org
Change-Id: I8dbe545a12c086f675972bdba60c94998268311a
Reviewed-on: https://chromium-review.googlesource.com/472247
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44731}
When asked for a module that previously failed to compile or
instantiate, the embedder necessarily has to signal failure. In this
case, we expect an exception to be scheduled, which we will rethrow.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2827733002
Cr-Commit-Position: refs/heads/master@{#44729}
Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
which was previously mostly done in JSTypedLowering (for no reason).
Add new logic to the lowering to constant-fold OrdinaryHasInstance
checks when the map of the left-hand side and the "prototype" of the
right-hand side is known. This address the performance issue with the
(base) class constructors generated by Babel, i.e.:
function _classCallCheck(instance, Constructor) {
if (!(instance instanceof Constructor)) {
throw new TypeError("Cannot call a class as a function");
}
}
var C = function C() { _classCallCheck(this, C); };
for
class C {}
Also ensure that a known constructor being used inside an instanceof
get's a proper initial map on-demand.
BUG=v8:6275
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2827013002
Cr-Commit-Position: refs/heads/master@{#44727}
When adding or overwriting properties of an object, the generic
keyed store stub must check if that property's name might have
an associated protector (e.g. the ArraySpeciesProtector) and
take the slow path if so to ensure that the protector is updated
as needed.
BUG=v8:6269
Review-Url: https://codereview.chromium.org/2821213004
Cr-Commit-Position: refs/heads/master@{#44726}
1) Function recording conditions need to be consistent (this same condition is used above)
2) byte is not wide enough for storing the backing store size.
Bugs uncovered by the existing tests with the flag on.
BUG=v8:5516
Change-Id: Iec6aff0cf1858afe1083526e4ada9a8eca08f062
Reviewed-on: https://chromium-review.googlesource.com/481320
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44724}
This includes a fastpath in the ElementsAccessor for the source
array being a JSArray with FastSmi or FastDouble packed kinds. This
is probably a pretty common usage, where an array is passed in as
a way of initializing the TypedArray at creation (as there is not other
syntax to do this). e.g. new Float64Array([1.0, 1.0, 1.0]) for some
sort of vector application.
BUG= v8:5977
Change-Id: Ice4ad9fc29f56b1c4b0b30736a1330efdc289003
Reviewed-on: https://chromium-review.googlesource.com/465126
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44722}
In particular the Babel generated code for simple constructors is
of interest here, since that's what we hit in the wild most often
currently.
BUG=v8:6275
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2822203004
Cr-Commit-Position: refs/heads/master@{#44719}
This new API sets a native data property on an object
directly, as Template::SetNativeDataProperty does.
It is similar to Object::SetAccessor, but properties
set by SetNativeDataProperty without kReadOnly flag
can be replaced.
Bug:chromium:617892
Change-Id: I32973f7190906d76be6802da9a0489edce0bd93e
Reviewed-on: https://chromium-review.googlesource.com/479474
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Hitoshi Yoshida <peria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44716}
This fixes source position tracking within the "increment" expression of
a for-statement. The old {StashCode} method was inherently incompatible
with side tables like the source position table, as it would leave them
untouched while mutating the bytecode stream. It was hence trimmed down
to {DeleteCode}.
R=bradnelson@chromium.org
BUG=v8:6127
Change-Id: I7a5ff60cd5334208c44b165c8b54144d9ae83209
Reviewed-on: https://chromium-review.googlesource.com/480301
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44714}
The typing rule for JSCreateArguments must properly declare rest
parameters as arrays and only consider sloppy and strict arguments
objects as Type::OtherObject.
TBR=jarin@chromium.org
BUG=v8:6262,chromium:712802
Review-Url: https://codereview.chromium.org/2828573004
Cr-Commit-Position: refs/heads/master@{#44712}
Functions that take mandatory parameters plus a number of optional
parameters, that need to be materialized as an Array are quite common.
The simplest possible case of this is essentially:
function foo(mandatory, ...args) { return args; }
Babel translates this to something like:
function foo(mandatory) {
"use strict";
for (var _len = arguments.length,
args = Array(_len > 1 ? _len - 1 : 0),
_key = 1; _key < _len; _key++) {
args[_key - 1] = arguments[_key];
}
return args;
}
The key to great performance here is to make sure that we don't
materialize the (unmapped) arguments object in this case, plus that we
have some kind of fast-path for the Array constructor and the
initialization loop.
This microbenchmark ensures that we have decent performance even in the
case where the assignment to args is polymorphic, i.e. the arguments
have seen different elements kinds, starting with FAST_HOLEY_ELEMENTS
and then FAST_HOLEY_SMI_ELEMENTS.
R=yangguo@chromium.org
BUG=v8:6262
Review-Url: https://codereview.chromium.org/2823343004
Cr-Commit-Position: refs/heads/master@{#44709}
It succeeds on my machine, at least, so marking pass/fail to avoid
unnecessary noise until the attached bug is resolved.
TBR=machenbach@chromium.org
Bug: v8:6252
Change-Id: I146eee0c464896e42058745096e929d221c04347
Reviewed-on: https://chromium-review.googlesource.com/480988
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44704}
When --harmony-strict-legacy-accessor-builtins is enabled, it brings
V8's behavior in line with the spec and more recent versions of
SpiderMonkey and JSC:
- No implicit receiver coercion
- Attempting to redefine a non-configurable property throws
Bug: v8:5070
Change-Id: I82b927538604136c0c550e19bcc606fbfea1377e
Reviewed-on: https://chromium-review.googlesource.com/478312
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44703}
What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:6175
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#44353}
Committed: 55905f85d6
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Commit-Position: refs/heads/master@{#44355}
Committed: cc74ea0bc4
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Commit-Position: refs/heads/master@{#44416}
Committed: f5dc738cda
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44702}
+ additional fixes uncovered by bug, and addressed remaining feedback
from original CL (https://codereview.chromium.org/2806073002/).
Note that the regression test differs slightly from the bug reported one,
in that it catches the RangeError which will eventually be thrown due
to call stack size being exceeded.
BUG=chromium:712569
Review-Url: https://codereview.chromium.org/2825073002
Cr-Commit-Position: refs/heads/master@{#44700}
This switches the parser to use token positions (i.e. {Position})
instead of stream positions (i.e. {GetPosition}) everywhere. Access to
the latter is being removed as it is unsupported when the scanner is in
rewind state anyways. This prevents "skipping" a token when seeking.
R=bradnelson@chromium.org
BUG=v8:6127
Change-Id: I9c13dd20a981061a2bccc4fb57e5c57d2a64ac5c
Reviewed-on: https://chromium-review.googlesource.com/480300
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44699}
- separated V8StackTraceImpl and AsyncStackTrace,
- V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
- V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
- async tasks are cleared with related async stacks.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2816043006
Cr-Original-Commit-Position: refs/heads/master@{#44670}
Committed: 1bca73bc83
Review-Url: https://codereview.chromium.org/2816043006
Cr-Commit-Position: refs/heads/master@{#44694}
The feature is not quite ready for getting ClusterFuzzed.
BUG=v8:5516
Change-Id: I90a42f950727c8ecf46cb2987c9a459b2ba1f5a7
Reviewed-on: https://chromium-review.googlesource.com/480400
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44693}
This fixes the de-duplication logic used when writing the deoptimizer
translation of a frame-state containing {kArgumentsElementsState}. The
object counts as a captured object and participates in the numbering of
duplicated objects.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-711166
BUG=chromium:711166
Change-Id: I4a3b892017ab8217197e5f94c1a0975d0cd6979f
Reviewed-on: https://chromium-review.googlesource.com/476631
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44692}
- Migrate make grokdump to GYP and GN
- Move code from d8 into stand-alone execution
- Add test case to ensure it's up-to-date
Review-Url: https://codereview.chromium.org/2809653003
Cr-Commit-Position: refs/heads/master@{#44687}
We can use TUPLE2 or TUPLE3 for structs that do not need special
handling by deoptimizer and compiler.
This frees up a few instance types, so that adding the next few
new structs will not cause ABI compatibility to break.
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2811183005
Cr-Commit-Position: refs/heads/master@{#44685}
This changes the message from
"method_name is not generic"
to
"method_name requires that 'this' be a primitive_name object"
BUG=v8:6206
Review-Url: https://codereview.chromium.org/2814043006
Cr-Commit-Position: refs/heads/master@{#44683}
Use Type::Array to constant-fold Array.isArray builtin based on the
value input type. Also use it to improve type based alias analysis,
where we know that stores to an object of type Array don't affect stores
to an object of type OtherObject, and vice versa.
R=jarin@chromium.org
BUG=v8:6262
Review-Url: https://codereview.chromium.org/2819583002
Cr-Commit-Position: refs/heads/master@{#44681}
No usage sites are getting the length for uncompiled functions, so we can
postpone setting the correct length until after compilation. This way we don't
need to produce and store it for skipped inner functions.
In the current implementation, getting the function length compiles it (and
users rely on it - so the feature is probably not going to go away).
BUG=v8:5516
Change-Id: Id8c9a05d2391505a6cde613841094170c9a1b808
Reviewed-on: https://chromium-review.googlesource.com/468927
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44679}
Reason for revert:
Speculative revert. Seems to block the roll:
https://codereview.chromium.org/2822983004/
Might require changing a browser test first?
Original issue's description:
> [inspector] avoid cloning of async call chains
>
> - separated V8StackTraceImpl and AsyncStackTrace,
> - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
> - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
> - async tasks are cleared with related async stacks.
>
> BUG=v8:6189
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2816043006
> Cr-Commit-Position: refs/heads/master@{#44670}
> Committed: 1bca73bc83TBR=dgozman@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6189
Review-Url: https://codereview.chromium.org/2825713002
Cr-Commit-Position: refs/heads/master@{#44678}
