In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.
With this change, we wait until after all argument conversions are done to set
the flag.
Bug: chromium:769846
R=bradnelson@chromium.org
Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}
This reverts commit 1f99c66b56.
Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226
Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637
> Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
> Reviewed-on: https://chromium-review.googlesource.com/693137
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48240}
TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:769637
Reviewed-on: https://chromium-review.googlesource.com/692918
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48242}
When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.
The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.
Bug: chromium:769637
Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
Reviewed-on: https://chromium-review.googlesource.com/693137
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48240}
This fixes the signature of "Math.abs" from "(signed) -> signed" to
"(signed) -> unsigned" and hence fixes cases where the absolute value
would overflow the range of signed 32-bit values. This is in sync with
spec erratas (and ECMAScript semantics).
Note that this also switches the underlying implementation of the above
absolute value function to a branch-free version.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-3
BUG=v8:6838
Change-Id: Ib13b7ecd336ae386cbde7c574e727bf52f841e00
Reviewed-on: https://chromium-review.googlesource.com/684181
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48169}
This fixes the signatures of "Math.ceil", "Math.floor" and "Math.sqrt"
from "(float?) -> float" to "(float?) -> floatish" which avoids using a
resulting float value without coercing the value via explicit "fround"
annotations. This ensures proper ECMAScript semantics are maintained.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-2
BUG=v8:6838
Change-Id: Ib5821641265bc862184adb270e8dbf8c703fdfb0
Reviewed-on: https://chromium-review.googlesource.com/681694
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48142}
This fixes the signature of "Math.min" and "Math.max" for integer values
from "(int, int...) -> signed" to "(signed, signed..) -> signed" which
properly distinguishes signed from unsigned values now. This is in sync
with the spec errata (and ECMAScript semantics).
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-1
BUG=v8:6838
Change-Id: Id72836513dd86e93472a22cf1ac2e2d382ed4f23
Reviewed-on: https://chromium-review.googlesource.com/681357
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48139}
Memory instantiate on initialize should always patch memory
references. If memory references are not patched for no initial
memory, on subsequent calls to grow_memory in wasm functions for
instances that share a module, the references will be patched
without resetting cloned compiled values to their correct initial
values.
BUG=chromium:763439
Change-Id: I666439332379b02aa344e99d61ef3dc88ab86cc8
Reviewed-on: https://chromium-review.googlesource.com/674707
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48097}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a
Reviewed-on: https://chromium-review.googlesource.com/657021
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48040}
SetForceInlineFlag is now only used in tests. Earlier, it was also used
in js builtins, because unless this flag was specified the js builtins
were not inlined. All the performance critical js builtins are moved
to turbofan builtins and SetForceInlineFlag is no longer used. We would
like to remove this flag completely to simplify inlining heuristics.
Also, this uses a bit on the SharedFuntionInfo.
Bug: v8:6682
Change-Id: I19afd27381afc212f29179f2c5477095c8174f39
Reviewed-on: https://chromium-review.googlesource.com/660739
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47997}
The wasm valiation incorrectly allowed simd locals, even without the
experimental flag turned on. This was not noted in the generated code
because simd opcodes were forbidden, but the interpreter could not
handle these locals.
R=clemensh@chromium.org
Bug: chromium:763697
Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80
Reviewed-on: https://chromium-review.googlesource.com/660117
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47946}
The Typer put the wrong type on String#index and String#lastIndexOf
builtins, with an off by one on the upper bound.
Bug: chromium:762874
Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932
Reviewed-on: https://chromium-review.googlesource.com/660000
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47942}
It's quite common today to use Function#apply together with typed
arrays, for example to construct a String from character codes (or code
points) within a Uint8Array or Uint16Array, i.e.
String.fromCharCode.apply(undefined, uint8array)
is seen quite often on the web. But there are other interesting cases
like
Math.max.apply(undefined, float64array)
to compute the maximum value in a Float64Array, which is definitely not
the fastest implementation, but quite convenient and readable.
Unfortunately these cases hit the super-slow-path of the Function#apply
machinery in V8 currently, because Function#apply doesn't have any
fast-path for TypedArrays.
This CL adds a proper fast-path to CreateListFromArrayLike to the
ElementsAccessor, which can be used as long as the typed array that's
passed wasn't neutered. With this fast-path in place, the performance on
the micro-benchmark mentioned in the issue improves from
stringFromCharCode: 6386 ms.
stringFromCodePoint: 8752 ms.
to
stringFromCharCode: 1932 ms.
stringFromCodePoint: 4262 ms.
which corresponds to a 2.0x-3.3x improvement.
Bug: v8:2435
Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
Reviewed-on: https://chromium-review.googlesource.com/657405
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47936}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
What happened:
- When rewriting in DoParseFunction, the relevant function scope is no longer in
the scope stack.
- The correct scope is given to the PatternRewriter.
- PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
- BuildIteratorCloseForCompletion would just call NewTemporary (which creates
a new temporary in Parser's current scope) instead of using the scope passed to
it and calling NewTemporary on it.
- Normally this went unnoticed, since it doesn't matter that much where the
temporary is.
- But in the lazy arrow func case, the Parser's scope at that point was the
already-resolved outer scope, and a DCHECK detected this problem.
Kudos & thanks to verwaest@ for a debugging session :)
BUG=chromium:761831
Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
Reviewed-on: https://chromium-review.googlesource.com/650297
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47877}
Prior to this, AllocateJSArray would go ahead and allocate an empty
FixedArray as elements if passed any capacity that is not a compile-time
constant 0.
Things break later on since we rely on the fact that empty fixed arrays
are always canonicalize, and we use
obj.elements == empty_fixed_array_constant
interchangeably with
obj.elements.length == 0.
This CL introduces two new branches in AllocateJSArray: one if the
capacity is known to be non-zero; and another that explicitly
distinguishes between 0 and non-zero capacities.
Bug: chromium:760790
Change-Id: I7c22b19ce9ce15a46f91b0f75e6b4a1ff3a29a0f
Reviewed-on: https://chromium-review.googlesource.com/645959
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47776}
This makes sure the minimum memory size for WebAssembly modules derived
from asm.js is set to zero. It allows instatiation without allocating an
underlying memory, when such memory is unused. It also fixes a bug in
patching of embedded memory sizes for asm.js modules.
R=ahaas@chromium.org
TEST=mjsunit/regress/regress-crbug-759327
BUG=chromium:759327
Change-Id: If5a965b96a03cbb5ba15bc41fbaf359f74961f41
Reviewed-on: https://chromium-review.googlesource.com/637912
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47646}
We cannot assume that the receiver is a JSObject, nor can we assume
ToObject() completes successfully.
TBR=yangguo@chromium.org
Bug: chromium:739954
Change-Id: Id55571131ef8755e86f15cd2acb918ff0f1b7788
Reviewed-on: https://chromium-review.googlesource.com/632376
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47611}
The Uint32(limit) conversion can end up transitioning the regexp
instance to slow mode. In this case we need to bail out to runtime while
ensuring that ToUint32 is not observably called a second time. We do
this by passing the already-converted value to runtime.
This particular path was broken and we ended up passing the original
maybe_limit value to runtime instead.
TBR=yangguo@chromium.org
Bug: chromium:758763
Change-Id: If7f23b452d2e134ad9be3d4ef1d78d1c946fcef0
Reviewed-on: https://chromium-review.googlesource.com/635588
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47609}
This makes sure instantiate of asm.js modules fails gracefully on heap
buffers exceeding the uint32_t range supported by WebAssembly.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-754175
BUG=chromium:754175
Change-Id: I4a9c6791beaab6da826b5b6b5a495f97e9d3b4e9
Reviewed-on: https://chromium-review.googlesource.com/632618
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47598}
BytecodeGenerator previously assumed that any UNALLOCATED variable
must be a global object property, but that's incorrect for global
lexical variables declared in a different script.
This patch fixes the behavior by always falling back to the runtime
to deal with deleting UNALLOCATED variables. This is sub-optimal,
but should be correct, and it's unclear if speed is important for
this case.
Bug: v8:6733
Change-Id: I83c2a0b6e30e5e5f4c79bfe14ebf196529816c71
Reviewed-on: https://chromium-review.googlesource.com/627636
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47554}
Due to shortcuts we take on the RegExp.p[@@split] fast path (we don't allocate
a new instance), we need to send sticky regexps to the slow path.
The problem is a slight impedance mismatch between the spec and our fast-path
implementation.
Spec: Creates a new regexp instance `splitter` that is guaranteed to be sticky,
uses `splitter.lastIndex` to advance the search range, advances by itself using
AdvanceStringIndex if `splitter` did not match at the current position.
Our fast path: Uses the given regexp instance and does not modify stickyness,
uses last_match_info to advance search range, returns (and assumes no more
matches) once RegExpExecInternal fails to match.
This is fine if the given regexp is non-sticky, since 1. the value of lastIndex
is ignored, and 2. non-sticky regexps match if a match is found anywhere in the
string, not just exactly at the current lastIndex.
Sticky regexps though are a problem. If no match is found exactly at the current
position, @@split assumes no more matches and exits.
In a follow-up, we could explore other options, such as allocating a new
instance or saving/restoring flags and lastIndex.
Bug: v8:6706
Change-Id: I6da2266df72b2f80f00c1ce3cd7c8655de91f680
Reviewed-on: https://chromium-review.googlesource.com/626065
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47543}
This makes sure that shift expressions (not wrapped in parentheses) can
appear as part of the index in a valid heap access expression. Only the
last operand of a sequence of shift expressions is taken into account
when validating the heap access.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-6700
BUG=v8:6700,chromium:754751
Change-Id: Icc7a71bd64461da4d3daea41b995964e3dfc6dc6
Reviewed-on: https://chromium-review.googlesource.com/623811
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47497}
If the elements fixed array is large enough, it must be allocated in
large-object space. This fixes two cases in which we'd incorrectly
assume elements fits into new space.
There are potentially quite a few other spots affected by a similar
issue, and we should find a more robust solution. See also:
crbug.com/636391.
Bug: v8:6716
Change-Id: I91f09355ac6b7cf399e13cc21d34113a506e58fb
Reviewed-on: https://chromium-review.googlesource.com/623808
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47495}
Before 983eec8979, RewritableExpressions
which had been queued for destructuring assignment rewriting but which
turned out to be part of a binding pattern in arrow function parameters
would be silently ignored by the PatternRewriter. After that CL, they
failed with a DCHECK.
This patch reverts to the previous behavior, with a TODO to handle this
in a better way by dequeuing RewritableExpressions that turned out
to be part of an inner arrow function.
Bug: chromium:756332
Change-Id: I0a9bf51499940c944034d9a8128e89950de38059
Reviewed-on: https://chromium-review.googlesource.com/619506
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47435}
The crash used to happen when trap is a Smi.
Bug: chromium:756608
Change-Id: I0a6f0328afc64d8e521b5b370a291f9aef6b08d0
Reviewed-on: https://chromium-review.googlesource.com/620647
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#47429}
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=yangguo@chromium.orgTBR=jarin@chromium.org
Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
This reverts commit 21da12a983.
Reason for revert: Failing on arm64 simulator
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.
Also does some other cleanup:
- Removes CompileUnoptimizedFunction and inlines into new Compiler function
- Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
out of FinalizeUnoptimizedCompile.
BUG=v8:6409
Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
In the case of a function constructor or eval, we create a new script
object which doesn't have a script name. In this case, we traverse
upwards on the list of SFI's through script->eval_from_shared() to get
the outermost script that was not an eval script and get the script
name from that script.
Bug: chromium:746909, v8:6683, v8:5785
Change-Id: I430459f632a0e3b18fc3111a5cf1c00cedb9f520
Reviewed-on: https://chromium-review.googlesource.com/606701
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47352}
It expected its argument to be a JSFunction, but fuzzer tests can
pass anything. Non-JSFunction arguments should just silently be
ignored, just like similar CF-whitelisted runtime functions do.
Bug: chromium:754177
Change-Id: I41b29528bbe72f24b3d84f021b22602160769d26
Reviewed-on: https://chromium-review.googlesource.com/610706
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47316}
When lazy-compiling, it is important we reconstitute the
ModuleEnv accurately. Besides addressing a bug, this change
also does away with the need to relocate memory and globals
parameters (in lazy compilation), by using "the right ones" upfront.
Bug: chromium:753496
Change-Id: I1412a499f05d02d49319fced1b3047698328f3b5
Reviewed-on: https://chromium-review.googlesource.com/609376
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47280}
This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
This changes the DCHECK (which could correctly fail) to be part of the
conditional that checks if we're in an async function.
Bug: chromium:751789
Change-Id: I3b8c1239ac93190055622c41fa1122e83b69d255
Reviewed-on: https://chromium-review.googlesource.com/607356
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47261}
Because SizeFor only returns aligned values, when we check values
returned there against kMaxSize, they can be larger if they were
rounded up.
It wasn't possible to write a test for the 2-byte version that didn't
regularly OOM.
Bug: chromium:752764
Change-Id: Id2f387449e0fafe633a2fde1ac728be31487f62d
Reviewed-on: https://chromium-review.googlesource.com/607935
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47252}
