We can't assume that there's no entered context during microtask
execution. We also can't assume that we'll never enter an context during
microtask execution either.
We can however assume that we don't execute microtasks recursively, so
remembering the length of the entered context stack is enough to decide
which context to use.
BUG=chromium:635769
R=verwaest@chromium.org
Review-Url: https://codereview.chromium.org/2350933007
Cr-Commit-Position: refs/heads/master@{#39627}
This reverts commit b42ecda533.
That commit introduced a allocator field to hashmap, which indirectly
added a field to Scopes, where the field, effectively storing a Zone, is
unnecessary because the Zone can be accessed in other ways.
Review-Url: https://codereview.chromium.org/2351393003
Cr-Commit-Position: refs/heads/master@{#39623}
Generate TBZ/TBNZ for certain comparisons against zero. E.g. instead of:
cmp w0, 0x0
b.lt/ge <addr>
we can generate:
tbnz/tbz w0, 31, <addr>
BUG=
Review-Url: https://codereview.chromium.org/2359723004
Cr-Commit-Position: refs/heads/master@{#39620}
If a JSCallFunction node doesn't have any callee information, either
from feedback taken on input nodes, i.e. on property loads, or from
the CallIC, we insert a soft deoptimization exit instead.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2361773002
Cr-Commit-Position: refs/heads/master@{#39619}
Port for VisitFloat32Add, VisitFloat64Add, VisitFloat32Sub and
VisitFloat64Sub in InstructionSelector.
TEST=unittests/InstructionSelectorTest.Float32AddWithFloat32Mul,
unittests/InstructionSelectorTest.Float64AddWithFloat64Mul,
unittests/InstructionSelectorTest.Float32SubWithFloat32Mul,
unittests/InstructionSelectorTest.Float64SubWithFloat64Mul
BUG=
Review-Url: https://codereview.chromium.org/2341303002
Cr-Commit-Position: refs/heads/master@{#39616}
This makes sure cycles in the object states graph are detected early by
escape analysis instead of late in the scheduler. This is mainly done
for improved debuggability.
R=bmeurer@chromium.org
BUG=chromium:613923
Review-Url: https://codereview.chromium.org/2354263002
Cr-Commit-Position: refs/heads/master@{#39614}
Reason for revert:
Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/
Original issue's description:
> [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.
>
> This CL optimizes the code in BytecodeArrayBuilder and
> BytecodeArrayWriter by making the following main changes:
>
> - Move operand scale calculation out of BytecodeArrayWriter to the
> BytecodeNode constructor, where the decision on which operands are
> scalable can generally be statically decided by the compiler.
> - Move the maximum register calculation out of BytecodeArrayWriter
> and into BytecodeRegisterOptimizer (which is the only place outside
> BytecodeGenerator which updates which registers are used). This
> avoids the BytecodeArrayWriter needing to know the operand types
> of a node as it writes it.
> - Modify EmitBytecodes to use individual push_backs rather than
> building a buffer and calling insert, since this turns out to be faster.
> - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
> bytes,
> - Make common functions in Bytecodes constexpr so that they
> can be statically calculated by the compiler.
> - Move common functions and constructors in Bytecodes and
> BytecodeNode to the header so that they can be inlined.
> - Change large static switch statements in Bytecodes to const array
> lookups, and move to the header to allow inlining.
>
> I also took the opportunity to remove a number of unused helper
> functions, and rework some others for consistency.
>
> This reduces the percentage of time spent in making BytecodeArrays
> in CodeLoad from ~15% to ~11% according to perf. The
> CoadLoad score increase by around 2%.
>
> BUG=v8:4280
>
> Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
> Cr-Commit-Position: refs/heads/master@{#39599}
TBR=mythria@chromium.org,leszeks@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:4280
Review-Url: https://codereview.chromium.org/2360193003
Cr-Commit-Position: refs/heads/master@{#39612}
This CL optimizes the code in BytecodeArrayBuilder and
BytecodeArrayWriter by making the following main changes:
- Move operand scale calculation out of BytecodeArrayWriter to the
BytecodeNode constructor, where the decision on which operands are
scalable can generally be statically decided by the compiler.
- Move the maximum register calculation out of BytecodeArrayWriter
and into BytecodeRegisterOptimizer (which is the only place outside
BytecodeGenerator which updates which registers are used). This
avoids the BytecodeArrayWriter needing to know the operand types
of a node as it writes it.
- Modify EmitBytecodes to use individual push_backs rather than
building a buffer and calling insert, since this turns out to be faster.
- Initialize BytecodeArrayWriter's bytecode vector by reserving 512
bytes,
- Make common functions in Bytecodes constexpr so that they
can be statically calculated by the compiler.
- Move common functions and constructors in Bytecodes and
BytecodeNode to the header so that they can be inlined.
- Change large static switch statements in Bytecodes to const array
lookups, and move to the header to allow inlining.
I also took the opportunity to remove a number of unused helper
functions, and rework some others for consistency.
This reduces the percentage of time spent in making BytecodeArrays
in CodeLoad from ~15% to ~11% according to perf. The
CoadLoad score increase by around 2%.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2351763002
Cr-Commit-Position: refs/heads/master@{#39599}
This add support for ConsString objects allocated inline to the escape
analysis pass. The raw hash field in such strings needs special handling
similar to existing raw fields. This also contains materialization code
within the deoptimizer as usual.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648737
BUG=chromium:648737
Review-Url: https://codereview.chromium.org/2357153002
Cr-Commit-Position: refs/heads/master@{#39594}
Each stub should have more meaningful descriptor instead.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2356163002
Cr-Commit-Position: refs/heads/master@{#39593}
This also adds sources missing for PPC and x87, fixes a few
missing files in gyp due to wrong quotation and a few that
were simply not included.
The gn files are now authoritative, but the gcmole gyp and
gn source lists are enforced to match exactly.
This additional enforcement helped finding the bugs above
and will be removed when we deprecate the gyp files.
BUG=614645
NOTRY=true
Review-Url: https://codereview.chromium.org/2352103002
Cr-Commit-Position: refs/heads/master@{#39592}
This cleanup is necessary to make HCallWithDescriptor support passing arguments on the stack.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2352163004
Cr-Commit-Position: refs/heads/master@{#39590}
This removes an optimization from the code generator that tries to
materialize certain constants (i.e. context and closure) from the
stackframe when possible. This does not work with Harmony tail calls
which are split into several instructions. There have already been
numerous bugs in this optimization, it is too fragile in its current
form.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648539
BUG=chromium:648539
Review-Url: https://codereview.chromium.org/2357583003
Cr-Commit-Position: refs/heads/master@{#39583}
After parsing a function, if there's no masking declaration in the function scope, DeclareFunctionVar will also bind the function name to a variable. It will either bind it to the const/const-legacy function_ variable, or to a dynamic non-local if the function calls sloppy eval.
Even if the variable is masked or sloppy eval is called, we still declare the function-var. The client immediately sets up the variable by assigning the resulting function to it.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2274133002
Cr-Commit-Position: refs/heads/master@{#39581}
When we added the new MachineRepresentation::kTaggedSigned and
MachineRepresentation::kTaggedPointer, we didn't extend the logic
for memory operand covering, and so for map checks and other
comparisons with fields we'd always need an additional register.
This fixes that and does reduce register pressure in some cases.
R=jarin@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2354863003
Cr-Commit-Position: refs/heads/master@{#39575}
Runtime.evaluate can return result by value. We need to provide more details why method call was failed.
BUG=chromium:645640
R=dgozman@chromium.org,alph@chromium.org
Review-Url: https://codereview.chromium.org/2345263003
Cr-Commit-Position: refs/heads/master@{#39574}
- Add a new container object to store the data required for
PromiseResolveThenableJob.
- Create a new runtime function to enqueue the microtask event with
the required data.
This patches causes a 4% regression in the bluebird benchmark.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2314903004
Cr-Commit-Position: refs/heads/master@{#39571}
This patch gives the ability for the embedder to ask for the
module requests of a module, and to pass a ResolveCallback
into Module::Instantiate().
In d8, I've implemented a simple module_map that's used
along with this API to allow loading, compiling, instantiating,
and evaluating a whole tree of modules.
No path resolution is yet implemented, meaning that all
import paths are relative to whatever directory d8 runs
in. And no imports are linked to the exports of the
requested module.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2351113004
Cr-Commit-Position: refs/heads/master@{#39569}
This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2353623002
Cr-Commit-Position: refs/heads/master@{#39567}
This patch uses temporaries rather than unresolved variables for
.promise and .debug_is_active. For .promise, a new field is added
to the FunctionState, similarly to .generator_object. This change
fixes a bug where .promise was locally shadowable by with, affecting
program semantics.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2359513002
Cr-Commit-Position: refs/heads/master@{#39566}
To improve performance, this patch makes Promise.all and Promise.race not
perform correct catch prediction when the debugger is not open. The case
may come up if Promise.race or Promise.all is called, then DevTools is
open, then a component Promise is rejected. In this case, the user would
falsely get an exception event even if the "pause on caught exceptions"
box is unchecked. There are tests which triggered this case; however, it
seems both unlikely and and acceptable to have an event in this case.
Many analogous events are already produced when DevTools is enabled
during the operation of a program.
BUG=v8:3093
Review-Url: https://codereview.chromium.org/2350363002
Cr-Commit-Position: refs/heads/master@{#39565}
This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
is a Promise, from the awaited value to the Promise under construction
in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
stack, to the Promise under construction in the async function that
surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
Promise from an async function)
In this reland, the caught tests are broken up into four parts to avoid
timeouts.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2346363004
Cr-Commit-Position: refs/heads/master@{#39564}
The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2341743003
Cr-Commit-Position: refs/heads/master@{#39562}
Fix a typo in TypeFeedbackVector::ComputeCounts, where we would not
skip the interpreter binary/compare op IC slots for fullcodegen, and
thus mess up the heuristics for tearing up.
TBR=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2353513006
Cr-Commit-Position: refs/heads/master@{#39560}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
Here we only change the type of the slot set fields to atomic values and use CAS to change the state. There is no change in behavior or semantics of the slot set.
BUG=chromium:648568
Review-Url: https://codereview.chromium.org/2353553003
Cr-Commit-Position: refs/heads/master@{#39557}
Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.
As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.
This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.
BUG=
Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}
- Eliminates *all* copies in the process.
- Moves (nearly) all functionality into Scanner::BookmarkScope.
- Significant code reduction.
[Needs to be rebased once crrev.com/2347883002 lands. All changes in *parser* are from that CL.]
R=marja@chromium.org
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2341323002
Cr-Commit-Position: refs/heads/master@{#39554}
This makes sure generator functions are marked as optimizable for all
configurations where the BytecodeGraphBuilder is used. Note that as
usual AstNumbering is just a heuristic and the underlying compiler can
still bailout from optimization when the compilation pipeline chooses
another compiler that does not support generator functions.
R=bmeurer@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2353793003
Cr-Commit-Position: refs/heads/master@{#39553}
Due to a typo, long branches were emitted instead of short branches, and the
code would stop working at all in the situation when long branches must be
emitted. This patche fixes this issue.
TEST=mjsunit/wasm/embenchen/lua_binarytrees
BUG=
Review-Url: https://codereview.chromium.org/2351143002
Cr-Commit-Position: refs/heads/master@{#39552}
The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887
Review-Url: https://codereview.chromium.org/2356733002
Cr-Commit-Position: refs/heads/master@{#39551}
This will allow to simplify the miss part of store IC handlers when we decide
to pass value/slot/vector on the stack.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2351643005
Cr-Commit-Position: refs/heads/master@{#39549}
This means we can no longer take the closure's context to parse, but
need to rely on the outer scope info.
Since it's not possible to get that, however, for lazy functions, we
introduce a new field to SharedFunctionInfo that stores the outer scope
info whenever available.
BUG=v8:5215
R=marja@chromium.org,verwaest@chromium.org,jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2358503002
Cr-Commit-Position: refs/heads/master@{#39548}
Removes some unnecessary probing in TemplateHashMapImpl, in
particular probing a second time in LookupOrInsert after the
first probe came up with an empty value.
Review-Url: https://codereview.chromium.org/2349163002
Cr-Commit-Position: refs/heads/master@{#39545}
... because the latter automatically respects the desired calling convention.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2350423002
Cr-Commit-Position: refs/heads/master@{#39543}
Extract String feedback on Add operation and utilize to lower ConsString
creation in JSTypedLowering when we know that a String addition will
definitely result in the creation of a ConsString.
Note that Crankshaft has to guard the potential length overflow of the
resulting string with an eager deoptimization exit, while we can safely
throw an exception in that case.
Also note that the bytecode pipeline does not currently provide the
String feedback for the addition, which has to be added.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2354853002
Cr-Commit-Position: refs/heads/master@{#39540}
Moves the hashmap's allocator from being a parameter in the various
hashmap functions, to being a field in the hashmap itself. This
1. Protects against incorrectly passed allocators, and
2. Cleans up the API so that e.g. callers don't have to store their
allocator
This is part of a wider set of changes discussed in:
https://groups.google.com/forum/#!topic/v8-dev/QLsC0XPYLeM
Review-Url: https://codereview.chromium.org/2345233003
Cr-Commit-Position: refs/heads/master@{#39538}
Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup
variables that can be globally loaded, without calling the runtime, as long as
there was no context extension by a sloppy eval along their context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2347143002
Cr-Commit-Position: refs/heads/master@{#39537}
... because the latter automatically respects the desired calling convention.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2358533002
Cr-Commit-Position: refs/heads/master@{#39535}
When an allocation for a parent object is pretenured, also propagate
that to all allocations for objects that are (potentially) stored into
the parent object.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2348293003
Cr-Commit-Position: refs/heads/master@{#39534}
Avoid internalizing on-the-fly now that scope analysis and natives syntax
runtime calls no longer require internalized AST values. This should be
more efficient by avoiding extra branches on every AST value creation.
BUG=v8:5215, chromium:634953
Review-Url: https://codereview.chromium.org/2328593002
Cr-Commit-Position: refs/heads/master@{#39531}
Adds template parameters for the TemplateHashMapImpl for the key and
value type, to allow them to be something other than pointers. To keep
the impact of this patch low, uses of TemplateHashMapImpl set these
types to void* to emulate the previous behaviour.
This is part of a wider set of changes discussed in:
https://groups.google.com/forum/#!topic/v8-dev/QLsC0XPYLeM
Review-Url: https://codereview.chromium.org/2343123002
Cr-Commit-Position: refs/heads/master@{#39530}
Reason for revert:
Unblocking roll
Original issue's description:
> [d8] Fix the shared-library build
>
> This commit ensures that the d8 shared library build uses the same logic as
> the standard static build by exporting relevant functions and classes.
>
> BUG=chromium:646337
>
> Committed: https://crrev.com/2c10ca8086a4d595ecf9aa843d2031b068470d65
> Cr-Commit-Position: refs/heads/master@{#39503}
TBR=jochen@chromium.org,vogelheim@chromium.org,bmeurer@chromium.org,titzer@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:646337
Review-Url: https://codereview.chromium.org/2356703003
Cr-Commit-Position: refs/heads/master@{#39526}
Crankshaft just unconditionally deoptimizes the code when the length of
a string addition result would overflow. In order to protect against
deopt loops we insert a global protector cell.
We will use the same mechanism for inlining certain string additions
into TurboFan as well, and protecting against overflow (we will also
extend this to deal with String.prototype.concat and friends once we
get there).
BUG=v8:5404
R=jarin@chromium.org,hpayer@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_msan_rel
Committed: https://crrev.com/cb19257a926a55209a6d6858ce26d51a0447ba71
Review-Url: https://codereview.chromium.org/2348293002
Cr-Original-Commit-Position: refs/heads/master@{#39511}
Cr-Commit-Position: refs/heads/master@{#39525}
Reason for revert:
Need to break up test into smaller tests to avoid timeouts
Original issue's description:
> Async/await Promise dependency graph
>
> This patch knits together Promises returned by async/await such that when
> one async function awaits the result of another one, catch prediction works
> across the boundaries, whether the exception comes synchronously or
> asynchronously. Edges are added in three places:
> - When a locally uncaught await happens, if the value passed into await
> is a Promise, from the awaited value to the Promise under construction
> in the broader async function
> - From a "throwaway" Promise, which may be found on the Promise debug
> stack, to the Promise under construction in the async function that
> surrounds it
> - When a Promise is resolved with another Promise (e.g., when returning a
> Promise from an async function)
>
> BUG=v8:5167
>
> Committed: https://crrev.com/7265fdde7c76b9f875b40b0b139515936d491d64
> Cr-Commit-Position: refs/heads/master@{#39522}
TBR=adamk@chromium.org,jgruber@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:5167
Review-Url: https://codereview.chromium.org/2351953002
Cr-Commit-Position: refs/heads/master@{#39523}
This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
is a Promise, from the awaited value to the Promise under construction
in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
stack, to the Promise under construction in the async function that
surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
Promise from an async function)
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2317383002
Cr-Commit-Position: refs/heads/master@{#39522}
This patch closes a memory leak in async/await where the desugaring
was creating a situation analagous to that described in v8:5002.
Intermediate Promises were being kept alive, so a long-running loop
would cause linear memory usage on the heap. This patch returns
undefined to the 'then' callback passed into PerformPromiseThen
in order to avoid this hazard. Test expectations are fixed to remove
expecting extraneous events which occurred on Promises that are
now not given unnecessarily complex resolution paths before being
thrown away.
This patch is a reland; originally, tests which exercised the memory
exhaustion were checked in. Although it's possible to find good parameters
for running such tests locally, it is difficult to automate the tests
between the rock of timeouts and the hard place of too-small heaps
causing memory exhaustion in some modes even when there is no leak.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2352933002
Cr-Commit-Position: refs/heads/master@{#39520}
We must keep track of the exact order in which modules are requested.
To do so, maintain a map from module specifiers to position while
parsing (in ModuleDescriptor). Descriptor entries now refer to that
position rather than the string. When generating the ModuleInfo, turn
this map into an array of specifiers. We don't need the map anymore
later on, so we do not reconstruct it when deserializing again.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2353633002
Cr-Commit-Position: refs/heads/master@{#39519}
Reason for revert:
Mean https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10910
Original issue's description:
> [crankshaft] Protect against deopt loops from string length overflows.
>
> Crankshaft just unconditionally deoptimizes the code when the length of
> a string addition result would overflow. In order to protect against
> deopt loops we insert a global protector cell.
>
> We will use the same mechanism for inlining certain string additions
> into TurboFan as well, and protecting against overflow (we will also
> extend this to deal with String.prototype.concat and friends once we
> get there).
>
> BUG=v8:5404
> R=jarin@chromium.org,hpayer@chromium.org
>
> Committed: https://crrev.com/cb19257a926a55209a6d6858ce26d51a0447ba71
> Cr-Commit-Position: refs/heads/master@{#39511}
TBR=hpayer@chromium.org,jarin@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5404
Review-Url: https://codereview.chromium.org/2357433002
Cr-Commit-Position: refs/heads/master@{#39518}
Handle the case of asm.js modules that return a single function
instead of a collection of them.
R=mtrofin@chromium.org
TEST=mjsunit/asm/asm-wasm
BUG=v8:4203
BUG=v8:5356
Review-Url: https://codereview.chromium.org/2348383003
Cr-Commit-Position: refs/heads/master@{#39515}
Reason for revert:
Still causes issues on bot (sometimes!)
Original issue's description:
> Reland of Fix async/await memory leak (patchset #1 id:1 of https://codereview.chromium.org/2354473002/ )
>
> Reason for revert:
> Relanding with faster-running test
>
> Original issue's description:
> > Revert of Fix async/await memory leak (patchset #5 id:80001 of https://codereview.chromium.org/2334323006/ )
> >
> > Reason for revert:
> > newly introduced test async-await-loop times out: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10894/steps/Ignition%20-%20turbofan%20%28flakes%29/logs/async-await-loop
> >
> > Original issue's description:
> > > Fix async/await memory leak
> > >
> > > This patch closes a memory leak in async/await where the desugaring
> > > was creating a situation analagous to that described in v8:5002.
> > > Intermediate Promises were being kept alive, so a long-running loop
> > > would cause linear memory usage on the heap. This patch returns
> > > undefined to the 'then' callback passed into PerformPromiseThen
> > > in order to avoid this hazard. Test expectations are fixed to remove
> > > expecting extraneous events which occurred on Promises that are
> > > now not given unnecessarily complex resolution paths before being
> > > thrown away.
> > >
> > > BUG=v8:5390
> > >
> > > Committed: https://crrev.com/a0ba18e9634c5e2d439033ab61a77cff54f9af35
> > > Cr-Commit-Position: refs/heads/master@{#39479}
> >
> > TBR=adamk@chromium.org,caitp@igalia.com,littledan@chromium.org
> > NOTRY=true
> > BUG=v8:5390
> >
> > Committed: https://crrev.com/196db1999da130019bbf8e3bd65977f840e8afaf
> > Cr-Commit-Position: refs/heads/master@{#39493}
>
> TBR=adamk@chromium.org,caitp@igalia.com,hablich@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> BUG=v8:5390
>
> Committed: https://crrev.com/e51482f01f26e0013e6377e85c4d2c41900e403c
> Cr-Commit-Position: refs/heads/master@{#39508}
TBR=adamk@chromium.org,caitp@igalia.com,hablich@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2348403003
Cr-Commit-Position: refs/heads/master@{#39512}
Crankshaft just unconditionally deoptimizes the code when the length of
a string addition result would overflow. In order to protect against
deopt loops we insert a global protector cell.
We will use the same mechanism for inlining certain string additions
into TurboFan as well, and protecting against overflow (we will also
extend this to deal with String.prototype.concat and friends once we
get there).
BUG=v8:5404
R=jarin@chromium.org,hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2348293002
Cr-Commit-Position: refs/heads/master@{#39511}
Previously we didn't implement TRACE_STR_COPY when we write trace events to
file, which causes us to allocate a growing independent memory chunk for dumped
runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
this memory allocation can be avoided, this patch removes it.
BUG=v8:5089
Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
Review-Url: https://codereview.chromium.org/2342643004
Cr-Original-Commit-Position: refs/heads/master@{#39462}
Cr-Commit-Position: refs/heads/master@{#39510}
This CL avoids relying on signed/unsigned implicit conversions
when re-computing wasm mem sizes.
BUG=
Review-Url: https://codereview.chromium.org/2349053002
Cr-Commit-Position: refs/heads/master@{#39509}
Reason for revert:
Relanding with faster-running test
Original issue's description:
> Revert of Fix async/await memory leak (patchset #5 id:80001 of https://codereview.chromium.org/2334323006/ )
>
> Reason for revert:
> newly introduced test async-await-loop times out: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10894/steps/Ignition%20-%20turbofan%20%28flakes%29/logs/async-await-loop
>
> Original issue's description:
> > Fix async/await memory leak
> >
> > This patch closes a memory leak in async/await where the desugaring
> > was creating a situation analagous to that described in v8:5002.
> > Intermediate Promises were being kept alive, so a long-running loop
> > would cause linear memory usage on the heap. This patch returns
> > undefined to the 'then' callback passed into PerformPromiseThen
> > in order to avoid this hazard. Test expectations are fixed to remove
> > expecting extraneous events which occurred on Promises that are
> > now not given unnecessarily complex resolution paths before being
> > thrown away.
> >
> > BUG=v8:5390
> >
> > Committed: https://crrev.com/a0ba18e9634c5e2d439033ab61a77cff54f9af35
> > Cr-Commit-Position: refs/heads/master@{#39479}
>
> TBR=adamk@chromium.org,caitp@igalia.com,littledan@chromium.org
> NOTRY=true
> BUG=v8:5390
>
> Committed: https://crrev.com/196db1999da130019bbf8e3bd65977f840e8afaf
> Cr-Commit-Position: refs/heads/master@{#39493}
TBR=adamk@chromium.org,caitp@igalia.com,hablich@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2348403002
Cr-Commit-Position: refs/heads/master@{#39508}
This is in preparation for upcmoming scanner + bookmarking cleanups.
Also, drive-by fix for setting a bookmark close to the end of the stream,
when the look-ahead character (c0_) is kEndOfInput, which the bookmarking
logic also used as kNoBookmark.
R=marja@chomium.org
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2345053003
Cr-Commit-Position: refs/heads/master@{#39507}
This commit ensures that the d8 shared library build uses the same logic as
the standard static build by exporting relevant functions and classes.
BUG=chromium:646337
Review-Url: https://codereview.chromium.org/2342563002
Cr-Commit-Position: refs/heads/master@{#39503}
According to the ES6 specification, in "for in/of" loops like:
for (var v of [1,2,3]) return f(...);
the call to f() should not be considered a tail call. This was
not working properly, i.e., the case without declarations:
var v;
for (v of [1,2,3]) return f(...);
R=adamk@chromium.org, ishell@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2343823002
Cr-Commit-Position: refs/heads/master@{#39497}
If the scope was lazily parsed, the ScopeInfo won't be correct (and we
won't store it in the SharedFunctionInfo).
BUG=chromium:644106
R=marja@chromium.org
Review-Url: https://codereview.chromium.org/2345243002
Cr-Commit-Position: refs/heads/master@{#39495}
Reason for revert:
newly introduced test async-await-loop times out: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10894/steps/Ignition%20-%20turbofan%20%28flakes%29/logs/async-await-loop
Original issue's description:
> Fix async/await memory leak
>
> This patch closes a memory leak in async/await where the desugaring
> was creating a situation analagous to that described in v8:5002.
> Intermediate Promises were being kept alive, so a long-running loop
> would cause linear memory usage on the heap. This patch returns
> undefined to the 'then' callback passed into PerformPromiseThen
> in order to avoid this hazard. Test expectations are fixed to remove
> expecting extraneous events which occurred on Promises that are
> now not given unnecessarily complex resolution paths before being
> thrown away.
>
> BUG=v8:5390
>
> Committed: https://crrev.com/a0ba18e9634c5e2d439033ab61a77cff54f9af35
> Cr-Commit-Position: refs/heads/master@{#39479}
TBR=adamk@chromium.org,caitp@igalia.com,littledan@chromium.org
NOTRY=true
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2354473002
Cr-Commit-Position: refs/heads/master@{#39493}
port 7f3d15aad423aabf2f9116a929c8fd750615610a(r39470)
original commit message:
In ignition, arguments to function calls and function constructors are
pushed onto the stack before calling the function. It is required to check
that stack does not overflow when pushing the arguments.
BUG=
Review-Url: https://codereview.chromium.org/2351543002
Cr-Commit-Position: refs/heads/master@{#39491}
port c7d7ca361dd1ba399becd54ce0d9c6e53f76c870(r39410)
original commit message:
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=
Review-Url: https://codereview.chromium.org/2352493002
Cr-Commit-Position: refs/heads/master@{#39490}
port 3ccedd5d8a24281b4abc0af4bfe41d4212a794e6(r39398)
original commit message:
BUG=
Review-Url: https://codereview.chromium.org/2352483002
Cr-Commit-Position: refs/heads/master@{#39489}
port 2ab3fcf42f0cf04896b26bf23bc3809d8835fd39(r39377)
original commit message:
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor
calls and normal calls (and thence, to record megamorphic call counts there as well).
BUG=
Review-Url: https://codereview.chromium.org/2351523002
Cr-Commit-Position: refs/heads/master@{#39487}
In practice this is a dense array, because there is currently no provision
in the format for assigning IDs other than sequentially to every object.
Thus a FixedArray is more efficient than a general dictionary.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2342293003
Cr-Commit-Position: refs/heads/master@{#39486}
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup.
- Fixed to use the setup method only once when CcTest::InitIsolateOnce is used.
- Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline.
R=mtrofin@chromium.org, ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2342263002
Cr-Commit-Position: refs/heads/master@{#39484}
Normally the parser just uses AstConsStrings to concatenate, but some
types require an AstRawString. This patch adds an AstValueFactory
method which produces one from two AstRawStrings.
Review-Url: https://codereview.chromium.org/2348783002
Cr-Commit-Position: refs/heads/master@{#39482}
This patch implements a bug fix to the async/await specification described
at https://github.com/tc39/ecma262/pull/692#issuecomment-247488411
Namely, the intermediate values of Promises may be rejected, and they do
not have .then called on them anymore (now that the memory leak is fixed),
but they do not correspond do unhandled rejections. This change has been
tested manually with integration with Blink; once it is checked in and
rolled, then further tests can be added on the Blink side for the uncaught
rejection handler and async/await.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2338273007
Cr-Commit-Position: refs/heads/master@{#39480}
This patch closes a memory leak in async/await where the desugaring
was creating a situation analagous to that described in v8:5002.
Intermediate Promises were being kept alive, so a long-running loop
would cause linear memory usage on the heap. This patch returns
undefined to the 'then' callback passed into PerformPromiseThen
in order to avoid this hazard. Test expectations are fixed to remove
expecting extraneous events which occurred on Promises that are
now not given unnecessarily complex resolution paths before being
thrown away.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2334323006
Cr-Commit-Position: refs/heads/master@{#39479}
For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.
Additionally, replace division by -1 with negation, and multiplication by two
with addition.
BUG=
Review-Url: https://codereview.chromium.org/2347573002
Cr-Commit-Position: refs/heads/master@{#39478}
Rename JSModule to Module and make it a Struct rather than a JSObject. We will
later add a separate JSModuleNamespace object to implement the 'import * as foo'
syntax.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2345823002
Cr-Commit-Position: refs/heads/master@{#39477}
This CL also cleans up related interface descriptors:
1) unused StoreTransitionDescriptor is removed and VectorStoreTransitionDescriptor is
renamed to StoreTransitionDescriptor.
2) on ia32/x87 architectures slot and vector are passed on the stack (dispatcher/handlers
cleanup will be addressed in a separate CL).
These two stub ports have to be combined in one CL because:
1) without changing the StoreTransitionDescriptor TF was not able to compile them
on ia32/x87 (because of lack of registers),
2) it was not possible to change the descriptor first because Crankshaft was not able
to deal with the stack allocated parameters in case of a stub failure.
TBR=jkummerow@chromium.org
BUG=v8:5269
Review-Url: https://codereview.chromium.org/2313093002
Cr-Commit-Position: refs/heads/master@{#39476}
Reason for revert:
Revert because this breaks V8's roll into Chromium. ASAN complains about memory accesses in a particular unit test.
Borked roll CL:
https://codereview.chromium.org/2348833002/
Reproduce breakage with:
1, args.gn:
v8_deprecation_warnings = true
use_goma = true
is_asan = true
2, ninja -C out/... content_browsertests
3, out/.../content_browsertests --gtest_filter=V8SamplingProfilerTest.*
Original issue's description:
> [Tracing] Remove unnecessary memory allocation in runtime call stats.
>
> Previously we didn't implement TRACE_STR_COPY when we write trace events to
> file, which causes us to allocate a growing independent memory chunk for dumped
> runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
> this memory allocation can be avoided, this patch removes it.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
> Cr-Commit-Position: refs/heads/master@{#39462}
TBR=cbruni@chromium.org,fmeawad@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2349593004
Cr-Commit-Position: refs/heads/master@{#39475}
Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup
variables that can be context loaded, without calling the runtime, as
long as there was no context extension by a sloppy eval along their
context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2343633002
Cr-Commit-Position: refs/heads/master@{#39473}
The predicate in question should only trigger once and hence the stack
height should not be updated incrementally. This puts checks into place
ensuring this holds.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2333923008
Cr-Commit-Position: refs/heads/master@{#39472}
Reason for revert:
This approach is not good - breaks when we recompile.
Original issue's description:
> Preparse inner functions.
>
> This is an overly pessimistic approach where PreParser only keeps
> track of unresolved variables, but doesn't declare anything. This
> will result in context-allocating variables in the outer function
> unnecessarily, if the variable names clash with variable names
> used by the inner function (even if the variables are not the
> same). However, we have been unable to prove that this approach
> wouldn't be good enough for the practical purposes.
>
> Committed: https://crrev.com/e1341ca8fa486bb2c9e4236672a64ec7756a164d
> Cr-Commit-Position: refs/heads/master@{#39469}
TBR=adamk@chromium.org,vogelheim@chromium.org,nikolaos@chromium.org,nednguyen@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2349473004
Cr-Commit-Position: refs/heads/master@{#39471}
In ignition, arguments to function calls and function constructors are
pushed onto the stack before calling the function. It is required to check
that stack does not overflow when pushing the arguments.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2335513004
Cr-Commit-Position: refs/heads/master@{#39470}
This is an overly pessimistic approach where PreParser only keeps
track of unresolved variables, but doesn't declare anything. This
will result in context-allocating variables in the outer function
unnecessarily, if the variable names clash with variable names
used by the inner function (even if the variables are not the
same). However, we have been unable to prove that this approach
wouldn't be good enough for the practical purposes.
Review-Url: https://codereview.chromium.org/2322243002
Cr-Commit-Position: refs/heads/master@{#39469}
During feedback typing (in SimplifiedLowering) we might be able to
constant-fold a bunch of ObjectIs<Type> predicates, i.e. because we
took type feedback on the input or we narrowed the type of a Phi
because of type feedback.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2342283002
Cr-Commit-Position: refs/heads/master@{#39468}
This ensures that {Compiler::EnsureBytecode} fails gracefully in case
the --ignition-filter flag prevents generation of bytecode for a certain
set of functions. This can be triggered via inlining.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2340293002
Cr-Commit-Position: refs/heads/master@{#39466}
- Smaller, more consistent streams API (Advance, Back, pos, Seek)
- Remove implementations from the header, in favor of creation functions.
Observe:
- Performance:
- All Utf16CharacterStream methods have an inlinable V8_LIKELY w/ a
body of only a few instructions. I expect most calls to end up there.
- There used to be performance problems w/ bookmarking, particularly
with copying too much data on SetBookmark w/ UTF-8 streaming streams.
All those copies are gone.
- The old streaming streams implementation used to copy data even for
2-byte input. It no longer does.
- The only remaining 'slow' method is the Seek(.) slow case for utf-8
streaming streams. I don't expect this to be called a lot; and even if,
I expect it to be offset by the gains in the (vastly more frequent)
calls to the other methods or the 'fast path'.
- If it still bothers us, there are several ways to speed it up.
- API & code cleanliness:
- I want to remove the 'old' API in a follow-up CL, which should mostly
delete code, or replace it 1:1.
- In a 2nd follow-up I want to delete much of the UTF-8 handling in Blink
for streaming streams.
- The "bookmark" is now always implemented (and mostly very fast), so we
should be able to use it for more things.
- Testing & correctness:
- The unit tests now cover all stream implementations,
and are pretty good and triggering all the edge cases.
- Vastly more DCHECKs of the invariants.
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2314663002
Cr-Commit-Position: refs/heads/master@{#39464}
Previously we didn't implement TRACE_STR_COPY when we write trace events to
file, which causes us to allocate a growing independent memory chunk for dumped
runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
this memory allocation can be avoided, this patch removes it.
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2342643004
Cr-Commit-Position: refs/heads/master@{#39462}
This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields
See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/
This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.
Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.
BUG=v8:5367
Review-Url: https://codereview.chromium.org/2315733003
Cr-Commit-Position: refs/heads/master@{#39459}
Previously, macro like PREPARE_FOR_EXECUTION_WITH_CALLBACK will end up calling
LOG_API, where we create a runtime call timer scope when we enable tracing with
runtime call stats, however since the flag will be enabled after calling
TRACE_EVENT_CALL_STATS_SCOPED, this will end up with incorrect timestamp. Thus,
we introduce a new macro
PREPARE_FOR_EXECUTION_WITH_CONTEXT_IN_RUNTIME_CALL_STATS_SCOPE, which will call
TRACE_EVENT_CALL_STATS_SCOPED inside it.
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2344723004
Cr-Commit-Position: refs/heads/master@{#39458}
We don't need the context anymore for parsing, the scope info chain is
enough.
BUG=v8:5215
R=marja@chromium.org,jgruber@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2342443004
Cr-Commit-Position: refs/heads/master@{#39457}
Reason for revert:
With fixes for frozen RegExps in https://codereview.chromium.org/2339443002 , it should be web-compatible to put RegExps in strict mode again, per spec.
Original issue's description:
> Revert of Put RegExp js code in strict mode (patchset #2 id:20001 of https://codereview.chromium.org/1776883005/ )
>
> Reason for revert:
> Found to break SAP Web IDE, and these semantics are not shipped in any other browser.
> Revert to legacy semantics while assessing web compatibility.
>
> BUG=chromium:624318
>
> Original issue's description:
> > Put RegExp js code in strict mode
> >
> > src/js/regexp.js was one of the few files that was left in sloppy
> > mode. The ES2017 draft specification requires that writes to
> > lastIndex throw when the property is non-writable, and test262
> > tests enforce this behavior. This patch puts that file in strict
> > mode.
> >
> > BUG=v8:4504
> > R=yangguo@chromium.org
> > LOG=Y
> >
> > Committed: https://crrev.com/80b1b2a45bbd9bf3d08e4e6516acfaaa8f438213
> > Cr-Commit-Position: refs/heads/master@{#34801}
>
> TBR=yangguo@chromium.org,adamk@chromium.org
>
> Committed: https://crrev.com/34880eb3dcf7492d44c0a3b45b6c888189f2c3c3
> Cr-Commit-Position: refs/heads/master@{#37449}
TBR=adamk@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:624318
Review-Url: https://codereview.chromium.org/2344773002
Cr-Commit-Position: refs/heads/master@{#39456}
This was one of the paths inside StackGuard that lacked a runtime counter,
making it hard to assess what was going on.
BUG=
Review-Url: https://codereview.chromium.org/2346863002
Cr-Commit-Position: refs/heads/master@{#39455}
There is no zero length array usage in inspector codebase. We can safely remove template specialization.
It was reverted to revert another patch and is good by itself.
BUG=chromium:635948
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2340193002
Cr-Commit-Position: refs/heads/master@{#39454}
To avoid a dependency on the heap during parsing, we only create a scope chain
without linking to the associated ScopeInfo objects before parsing. This is
enough to avoid special cases during parsing of arrow functions / eval.
Looking at the outer scope's variables during parsing was only needed for hosting
sloppy block functions inside eval. To be able to do this now, we hoist for the
outer-most eval scope after parsing, in DeclarationScope::Analyze.
DeclarationScope::Analyze is also where we replace the outer scope chain with the
fully deserialized version, so variables can be resolved.
Also, this unifies background and foreground thread parsing, as we don't have to
worry about ScopeInfos getting accessed before we're back on the main thread.
BUG=v8:5215
R=verwaest@chromium.org,marja@chromium.org,adamk@chromium.org
Review-Url: https://codereview.chromium.org/2306413002
Cr-Commit-Position: refs/heads/master@{#39452}
All parameters passed by reference must be labeled const.
If the object is mutable, then we pass by pointer.
BUG=
Review-Url: https://codereview.chromium.org/2336233006
Cr-Commit-Position: refs/heads/master@{#39451}
We used to intercept function definitions, but not declarations.
GenericNamedPropertySetterCallback now also intercepts function declarations.
For definitions, we call DeclareGlobal and then InitializeVarGlobal. For
declarations, we never call InitializeVarGlobal, thus we must check for
interceptors in DeclareGlobal.
If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only
property, an exception is thrown independent of whether an interceptor is
installed. Usually, i.e., not during a declaration, we only throw if
the call is not successfully intercepted.
BUG=v8:5375
Review-Url: https://codereview.chromium.org/2334733002
Cr-Commit-Position: refs/heads/master@{#39450}
This CL implements the throw wasm opcode. This is a pre-requisite for
implementing try-catches in wasm.
BUG=
Review-Url: https://codereview.chromium.org/2339053003
Cr-Commit-Position: refs/heads/master@{#39449}
This handles the case where generating bytecode for inlining purposes
causes a stack overflow. We just abort inlining but also need to clear
pending exceptions.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647217
BUG=chromium:647217
Review-Url: https://codereview.chromium.org/2339383002
Cr-Commit-Position: refs/heads/master@{#39448}
Port c7d7ca361d
Original commit message:
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=v8:5267,v8:5372
LOG=N
Review-Url: https://codereview.chromium.org/2338413002
Cr-Commit-Position: refs/heads/master@{#39446}
The semantics of the {BailoutId} representing an OSR entry point is
different between the interpreter and the full code generator. These
semantics are hard-coded in various graph builders. We need to ensure
that the correct graph builder is chosen for OSR compilations.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5380
BUG=v8:5380
Review-Url: https://codereview.chromium.org/2341663002
Cr-Commit-Position: refs/heads/master@{#39444}
Ignition requires that objects which will be inserted into the
constant pool are canonicalized (to enable off-thread bytecode
generation). We created a CanonicalizeHandleScope across parse/compile
however this impacts performance (~5-8% on CodeLoad).
Now we localize the CanonicalHandleScope to only the parse /
internalization and renumbering phases where objects are created which
could end up in the constant array pool. This seems to address
the performance regression.
BUG=v8:5203,chromium:634953
Review-Url: https://codereview.chromium.org/2318653002
Cr-Commit-Position: refs/heads/master@{#39443}
Reason for revert:
Regressions in telemetry benchmarks:
crbug.com/646819.
Original issue's description:
> [heap] Decouple old generation allocation limit from external memory.
>
> We check for external memory limit in Heap::ReportExternalMemoryPressure.
>
> BUG=chromium:616434
>
> Committed: https://crrev.com/672d079ccba686019fa1457c83b42c2e692ef88b
> Cr-Commit-Position: refs/heads/master@{#39374}
TBR=hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:616434
Review-Url: https://codereview.chromium.org/2339033005
Cr-Commit-Position: refs/heads/master@{#39442}
When zeroing a floating point stack slot, store the zero register directly,
rather than storing zero moved to an FP register.
BUG=
Review-Url: https://codereview.chromium.org/2339943002
Cr-Commit-Position: refs/heads/master@{#39441}
This is a first implementation of inlining into graphs that have been
created using the {BytecodeGraphBuilder}. Note that inlining sticks to
graphs of the same kind, we only ever inline AstGraph into AstGraph or
BytecodeGraph into BytecodeGraph, no mixed inlining.
R=bmeurer@chromium.org,rmcilroy@chromium.org
TEST=cctest/test-run-inlining
BUG=v8:5251
Review-Url: https://codereview.chromium.org/2262033003
Cr-Commit-Position: refs/heads/master@{#39439}
Migrate the platform DatePrototype_GetField (and all wrappers) to
TurboFan.
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2263533002
Cr-Commit-Position: refs/heads/master@{#39438}
This flag has been flipped off since 52, so it is due for removal.
R=adamk@chromium.org,caitp@igalia.com
BUG=v8:3785
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
Review-Url: https://codereview.chromium.org/2268633002
Cr-Commit-Position: refs/heads/master@{#39435}
In case of duplicate exports, always report the error for the very last
one.
(Fixed a bug.)
BUG=v8:5358,v8:1569
Review-Url: https://codereview.chromium.org/2340953002
Cr-Commit-Position: refs/heads/master@{#39434}
Handle the "synchronous case" by marking try/catch blocks introduced for
async functions as ASYNC_AWAIT and traversing up the stack, finding successive
Promises and returning caught if any of them are predicted to be caught.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2325813002
Cr-Commit-Position: refs/heads/master@{#39433}
Reason for revert:
needed to revert https://codereview.chromium.org/2339173004/
Original issue's description:
> [inspector] removed ArrayLengthHelperFunction specialization for empty array
>
> There is no zero length array usage in inspector codebase. We can safely remove template specialization.
>
> BUG=chromium:635948
> R=dgozman@chromium.org,alph@chromium.org
>
> Committed: https://crrev.com/b249ffc1915d8c35ff66eae3d51d3878d588dfbf
> Cr-Commit-Position: refs/heads/master@{#39428}
TBR=jochen@chromium.org,alph@chromium.org,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=chromium:635948
Review-Url: https://codereview.chromium.org/2334163006
Cr-Commit-Position: refs/heads/master@{#39431}
There is no zero length array usage in inspector codebase. We can safely remove template specialization.
BUG=chromium:635948
R=dgozman@chromium.org,alph@chromium.org
Review-Url: https://codereview.chromium.org/2340623002
Cr-Commit-Position: refs/heads/master@{#39428}
This exposes an interface for the embedder to provide a delegate which can
serialize or deserialize embedder-specific objects, like Blink's DOM wrappers.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2327653002
Cr-Commit-Position: refs/heads/master@{#39422}
Add a dedicated simplified operator to inline the general case for the
ToBoolean conversion. In a follow up CL we will also use the ToBoolean
hints gathered by the baseline compiler.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_arm64_gc_stress_dbg
R=jarin@chromium.org
BUG=v8:5267
Committed: https://crrev.com/8c50b51ab3d21efcd2f6900d83962159f21e1590
Review-Url: https://codereview.chromium.org/2167593002
Cr-Original-Commit-Position: refs/heads/master@{#37882}
Cr-Commit-Position: refs/heads/master@{#39420}
RegExpSubclassExecJS and RegExpExecJS only differed in the additional
TO_BOOLEAN on global and sticky flags and the useless (i < 0) check.
R=littledan@chromium.org
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2337923002
Cr-Commit-Position: refs/heads/master@{#39417}
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
This CL adds CSA::Retain() operation that ensures that the value is kept alive even during GC.
BUG=v8:5269
Review-Url: https://codereview.chromium.org/2330063002
Cr-Commit-Position: refs/heads/master@{#39407}
This removes some leftover code which avoided adding stack checks to
stubs being compiled via the normal JavaScript pipeline, which we no
longer do.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2333973003
Cr-Commit-Position: refs/heads/master@{#39404}
Extract the call counts from the type feedback vector during graph
building (either via the AstGraphBuilder or the BytecodeGraphBuilder),
and put them onto the JSCallFunction and JSCallConstruct operators,
so that they work even across inlinine through .apply and .call (which
was previously hacked by creating a temporary type feedback vector
for those).
The next logic step will be to make those call counts into real
relative call frequencies (also during graph building), so that we
can make inlining decisions that make sense for the function being
optimized (where absolute values are misleading).
R=jarin@chromium.org
BUG=v8:5267,v8:5372
Review-Url: https://codereview.chromium.org/2330883002
Cr-Commit-Position: refs/heads/master@{#39400}
Reason for revert:
Suspecting this is a roll blocker: https://codereview.chromium.org/2332343002/
#
# Fatal error in ../../v8/src/heap/spaces.h, line 1618
# Check failed: capacity_ >= bytes (25429824 vs. 18446744073709551168).
#
Original issue's description:
> [heap] Enable black allocation when finalizing incremental marking.
>
> BUG=chromium:630386
>
> Committed: https://crrev.com/1ccc742dc326b063999670421e1da0ea124874c0
> Cr-Commit-Position: refs/heads/master@{#39382}
TBR=mlippautz@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:630386
Review-Url: https://codereview.chromium.org/2340463005
Cr-Commit-Position: refs/heads/master@{#39397}
json-parser does the same thing. This drastically reduces GC cost when
deserializing objects large enough that multiple collections are likely
(since it saves the effort to move them to the old generation, when we
know that the objects we create will persist at least until the deserializer
finishes).
The threshold was chosen to match json-parser.
This patch reduces deserialization time on a large blob of JSON-y data
by approximately 30%.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2336973004
Cr-Commit-Position: refs/heads/master@{#39396}
v8::Isolate::Throw only schedules the exception; it is necessary to promote it
after invoking the delegate.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2332843003
Cr-Commit-Position: refs/heads/master@{#39395}
Handle some examples of the "asynchronous case" by marking await expressions
as either caught or uncaught; in the caught case, this marks the Promise passed
in as having a catch predicted. The marking is done in AST numbering, which
chooses between two different runtime function calls based on catch prediction.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2276243002
Cr-Commit-Position: refs/heads/master@{#39394}
The initial support for low level exception handling in Wasm will not
support finally blocks. This decision is taken for both simplicity (
handling finallys is not straightforward if we want try blocks to yield
values), and lack of good use case (clang++ does not need them.) They
may be added in the future once we understand the implications of
having them.
BUG=
Review-Url: https://codereview.chromium.org/2336303002
Cr-Commit-Position: refs/heads/master@{#39393}
This CL "weakens" the typer somewhat, as it was querying aspects of
Type that are within the representation dimension. It's not the right
place to do that.
BUG=
Review-Url: https://codereview.chromium.org/2320473003
Cr-Commit-Position: refs/heads/master@{#39391}
This reverts commit cf5180c3ef. It turns
out finally blocks aren't useful in the current incarnation of Wasm. We
might reintroduce it later.
BUG=
Review-Url: https://codereview.chromium.org/2330073002
Cr-Commit-Position: refs/heads/master@{#39390}
The AllocationResult already carries the information in which space the allocation failure happened.
BUG=
Review-Url: https://codereview.chromium.org/2333293002
Cr-Commit-Position: refs/heads/master@{#39387}
During GC multiple threads can request icache flush when evacuating
code space in parallel.
Simulator::FlushICache updates Isolate::simulator_icache hashmap,
which leads to a race.
This patch adds a lock for simulator_icache.
BUG=
Review-Url: https://codereview.chromium.org/2338793002
Cr-Commit-Position: refs/heads/master@{#39386}
This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.
R=rmcilroy@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2331033002
Cr-Commit-Position: refs/heads/master@{#39384}
When lowering DataField accesses, we should pay attention to the
MachineRepresentation reported by the AccessInfo. This doesn't
yet change the rest of the pipeline to take full advantage of
the representations.
Drive-by-fix: Make the code more robust, especially the part that
deals with mutable heap number access.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2334193002
Cr-Commit-Position: refs/heads/master@{#39381}
When inlining sloppy functions try to find some witness in the effect
chain that the receiver is already a JSReceiver and thereby avoid
inserting the JSConvertReceiver node, which we currently cannot really
optimize away most of the time.
Middle-term we may want to change the way CheckMaps works and have some
unified mechanism to deal with effect chain walks to find witnesses for
various map related facts. Also we may want to consider doing this
optimization later, although that requires some more refactorings since
we already promised that JSConvertReceiver gives a Type::Receiver.
R=mstarzinger@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2333213002
Cr-Commit-Position: refs/heads/master@{#39379}
Moves the context chain search loop out of generated bytecode, and into
the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
an additional operand. This should decrease the bytecode size and
increase performance for deep context chain searches, at the cost of
slightly increasing bytecode size for shallow context access.
Review-Url: https://codereview.chromium.org/2336643002
Cr-Commit-Position: refs/heads/master@{#39378}
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well).
BUG=
Review-Url: https://codereview.chromium.org/2325083003
Cr-Commit-Position: refs/heads/master@{#39377}
We check for external memory limit in Heap::ReportExternalMemoryPressure.
BUG=chromium:616434
Review-Url: https://codereview.chromium.org/2329993002
Cr-Commit-Position: refs/heads/master@{#39374}
This makes sure OSR entry points can be added without having special
{OsrPoll} instructions in the bytecode stream. Eventually we might end
up merging back-branches and OSR polls together. Any loop header can be
used as an OSR entry point.
R=bmeurer@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2329933003
Cr-Commit-Position: refs/heads/master@{#39373}
Don't sort inline candidates by comparing Node pointers, where the order
depends on the allocation order and the concrete Zone memory layout at
runtime. Instead sort based on NodeId, which is deterministic.
R=mvstanton@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2336113002
Cr-Commit-Position: refs/heads/master@{#39371}
Add strength reduction rules to optimize
CheckTaggedSigned(CheckTaggedSigned(x)) -> CheckTaggedSigned(x)
and
CheckTaggedPointer(CheckTaggedPointer(x)) -> CheckTaggedPointer(x)
where we do some cleanup optimizations after loop peeling and redundancy
elimination, which can generate these constructs.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2336093002
Cr-Commit-Position: refs/heads/master@{#39366}
This change avoids needing to keep around an unused compiled
module. Instead, the result of compiling the wasm bytes is
given to the first instance. The module object and that instance object
point to the same compiled module. Instances are, then, cloned from
the compiled module the module object points to. When an instance is
collected, we make sure that the module object still has a clone
available, and, if the last instance is GC-ed, we also reset the compiled
module so that it does not reference its heap, so that it (==heap) may
be collected.
This is achieved by linking the clones in a double-linked list and
registering a finalizer for each. When we create an instance, we tie it
in the front of the list, making the module object point to it (O(1)). When
the finalizer is called, we relink the list over the dying object (O(1)). The
costliest operation is finalizing the last instance, since we need to visit
all wasm functions and reset heap references.
BUG=v8:5316
Committed: https://crrev.com/01f5af515728aebe6c5246f4f7dd6c573e8748af
Review-Url: https://codereview.chromium.org/2305903002
Cr-Original-Commit-Position: refs/heads/master@{#39153}
Cr-Commit-Position: refs/heads/master@{#39361}
Moved the compilation/instantiation pipeline to work off the
module object (JSObject), making the compiled module data (the
FixedArray) an implementation detail. This:
- simplifies the code by removing duplicate decode->compile->instantiate
sequences
- sets up the stage for "dressing up" the runtime model with
stronger typed APIs
- helps relanding this CL: https://codereview.chromium.org/2305903002/.
It turns out that GCs during the cloning/instantiation events cause
trouble, and centering the source of truth on the module object helps
address this issue.
In the process, clarified cctest setup for wasm-capable isolates,
and changed signatures for consistency (using ModuleOrigin througout).
BUG=
Review-Url: https://codereview.chromium.org/2320723005
Cr-Commit-Position: refs/heads/master@{#39360}
The raw pointer to the parameter_map might get stale in case of accessors present on
the arguments object.
Drive-by-fix: use nullptr instead of the_hole with isolate access.
BUG=chromium:645680
Review-Url: https://codereview.chromium.org/2332503002
Cr-Commit-Position: refs/heads/master@{#39359}
The whitelist is populated with those inline intrinsics that are lowered
in JSIntrinsicInlining and were not previously blacklisted. Thus the only
additional FrameStates this CL adds are those where the caller tries to
call the INLINE version of an intrinsic but ends up calling the RUNTIME
version instead.
R=bmeurer@chromium.org
BUG=chromium:644631
Review-Url: https://codereview.chromium.org/2331543002
Cr-Commit-Position: refs/heads/master@{#39357}
Backtrace() and backtrace_symbols() API are not supported on
AIX and there are no user-mode equivalent API for the same.
For now, disabling the call to those API.
Currently this is preventing V8 to build on AIX.
This debug functionality was added in
https://codereview.chromium.org/2248393002R=rmcilroy@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2324453002
Cr-Commit-Position: refs/heads/master@{#39356}
This adds partial support of exports to the runtime system and
to the interpreter. It introduces a new HeapObject JSModule that
maps each of the module's export names to a Cell containing the
exported value.
Several aspects of this implementation are subject to change in
follow-up CLs.
BUG=v8:1569
Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17
Review-Url: https://codereview.chromium.org/2302783002
Cr-Original-Commit-Position: refs/heads/master@{#39341}
Cr-Commit-Position: refs/heads/master@{#39352}
With this CL the wasm-code-fuzzer first decodes and interprets the test
case generated by the fuzzer. It then compiles the test case, but only
executes the compiled instance if the interpretation of the test case
was successful. If the compiled instance is executed, then the result of
the execution is compared with the result of the interpretation.
Additionally this CL refactors the CompileAndRunWasmModule function in
wasm-module.cc to resuse code in the call to the interpreter.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2321443002
Cr-Commit-Position: refs/heads/master@{#39351}
We shall not mix AVX and SSE instructions as that can cause performance
regressions in some areas, so make sure to emit vsqrtsd instead of
sqrtsd when AVX is enabled.
R=ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2335603002
Cr-Commit-Position: refs/heads/master@{#39349}
This patch changes incremental marking work scheduling from combination
of idle/delayed tasks to ordinary short-running tasks and moves
more marking work from V8.Execute to tasks by accounting how much
bytes were marked in tasks.
BUG=chromium:616434
LOG=NO
Review-Url: https://codereview.chromium.org/2321553002
Cr-Commit-Position: refs/heads/master@{#39348}
Rework Runtime::FunctionForName to take a c-string instead of a v8::String
so that the parser can parse native syntax runtime calls without doing
on-the-fly internalization.
Also adds a c-string variant of IntrinsicIndexForName for the same reasons.
BUG=v8:5215,chromium:634953
Review-Url: https://codereview.chromium.org/2324803002
Cr-Commit-Position: refs/heads/master@{#39346}
Reason for revert:
Failures related to deopt.
Original issue's description:
> [modules] Basic support of exports
>
> This adds partial support of exports to the runtime system and
> to the interpreter. It introduces a new HeapObject JSModule that
> maps each of the module's export names to a Cell containing the
> exported value.
>
> Several aspects of this implementation are subject to change in
> follow-up CLs.
>
> BUG=v8:1569
>
> Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17
> Cr-Commit-Position: refs/heads/master@{#39341}
TBR=adamk@chromium.org,rmcilroy@chromium.org,ulan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2328283002
Cr-Commit-Position: refs/heads/master@{#39345}
This adds partial support of exports to the runtime system and
to the interpreter. It introduces a new HeapObject JSModule that
maps each of the module's export names to a Cell containing the
exported value.
Several aspects of this implementation are subject to change in
follow-up CLs.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2302783002
Cr-Commit-Position: refs/heads/master@{#39341}
It is invalid for OSR deconstruction to leave a graph with a node
representing the OSR normal entry (and no OSR loop entry). Subsequent
lowering phases will not handle {OsrNormalEntry} operators and hence
will lead to serious clogging further down the pipeline.
R=bmeurer@chromium.org
BUG=chromium:641893
Review-Url: https://codereview.chromium.org/2336543002
Cr-Commit-Position: refs/heads/master@{#39340}
With this CL the AstDecoder produces an error if it encounters a
grow_memory instruction in an asmjs module. Additionally asmjs
instructions are not allowed anymore in wasm modules.
BUG=chromium:644674
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2324733002
Cr-Commit-Position: refs/heads/master@{#39339}
