This sets us up for getting the wasm code generation off the GC heap.
We reference tables as global handles, which have a stable address. This
requires an extra instruction when attempting to make an indirect call,
per table (i.e. one for the signature table and one for the function
table).
Bug:
Change-Id: I83743ba0f1dfdeba9aee5d27232f8823981288f8
Reviewed-on: https://chromium-review.googlesource.com/612322
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47444}
The V8 API provides interceptors. They are not part of the
EcmaScript specification. But their behavior should be consistent.
For example, when an EnumeratorInterceptor is defined, Object.keys(),
Object.entries(), and Object.values() should all have the
same number of entries.
This CL creates consistent behavior among these
functions. If a QueryCallback is present, it is used to
filter the result from the EnumeratorCallback for
enumerable properties.
Bug: v8:6627
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie51e69bb77099d9fafc4b1ea02671eced610edba
Reviewed-on: https://chromium-review.googlesource.com/609068
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47442}
Currently, Declaration stores a Scope pointer to whichever Scope the
declaration appeared in. This is used to disallow var declarations
being hoisted over lexical declarations. For example:
{
let x;
{ var x; }
}
But in fact this is the only sort of case where storing the scope
is required: for lexical declarations (including function declarations
appearing in blocks), Declaration::scope() was always identical to
Declaration::proxy()->var()->scope(). That is, only var declarations
end up "nested" in this way.
This patch adds a subclass of VariableDeclaration to store the Scope.
Since the only thing that cares about that data is Scope analysis,
this isn't treated as a distinct AstNode::NodeType from VariableDeclaration,
leaving all AstVisitors untouched in the process.
Also reworked the logic in Scope::CheckConflictingVarDeclarations() for
clarity after making changes to accomodate the new code.
Change-Id: I6ee4298700508ab9e28a76ddb8504bae68bc473f
Reviewed-on: https://chromium-review.googlesource.com/619595
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47441}
In-process capture of exceptions doesn't work well because there's no
symbols on-device. Instead, just let the system crashlogger output a
backtrace that the run script can symbolize.
Bug: chromium:731217
Change-Id: I9a509a29e55229a5d8675c9bdc890b50a6a9bfb9
Reviewed-on: https://chromium-review.googlesource.com/619947
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47440}
This fixes layering between page and its owner, so that the page does
not update the owner state.
Bug: chromium:694255
Change-Id: Ic4f594340bed42d4f2c13d0a30f451317cbc9f50
Reviewed-on: https://chromium-review.googlesource.com/620732
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47437}
This patch removes unnecessary scope creation for C-style, for-in, and
for-of loops containing var declarations. Only loops with LET or CONST
declarations require additional scoping up-front.
After this patch lands, I intend to apply this simplification (as well
as that from fa15ba5a7b) to for-await loops.
Bug: v8:6724
Change-Id: I9962432d1e059d8eefb577e7b512bc2321a03140
Reviewed-on: https://chromium-review.googlesource.com/619987
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47436}
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}
This hides more implementation details and simplifies callers.
R=ahaas@chromium.org
Bug:
Change-Id: I4809611c55b810a3b0674713e12f3f17401e6c9c
Reviewed-on: https://chromium-review.googlesource.com/620713
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47434}
Many handlers are not used again, so we can improve the cache hit rate
by caching fewer handlers. Specifically, in this CL, when a StoreIC
miss causes a new map transition to be created, then the handler is not
cached right away yet (it will be cached next time, when the transition
exists already).
Also, fix an embarrassing bug where growing a TransitionArray dropped
cached handlers. That further improves the cache hit rate. ;-)
Bug: chromium:752867, chromium:753819
Change-Id: Id8db5ca1e780a5fe8fc61db7f20996e61c65a90e
Reviewed-on: https://chromium-review.googlesource.com/619851
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47433}
The TODO was about wrapping together the sourceposition iterator and the bytecode
iterator. Since the first one is useful in fewer parts than the second, and the
bytecode iterator is more flexible to advance than the sourceposition iterator,
and we would not gain that much more readability, this TODO is removed.
TBR=mstarzinger@chromium.org
Bug:
Change-Id: I104d0f5f0cd01686ea48d209419bd6bb2ed19bcf
Reviewed-on: https://chromium-review.googlesource.com/621106
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47432}
After dfc6b4d the space size can decrease if the sweeper discovers
new fillers added after marking (e.g. by array trimming).
Bug: chromium:756832
Change-Id: Ibf420593bd12a4fe13a1e47f862302025b52ad58
Reviewed-on: https://chromium-review.googlesource.com/620734
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47431}
(source_length - 1) can be overflowed, and cause OOB access when source_length
is zero. Thus, just do not operate setting if source_length is zero when
starting TypedArraySetFromOverlapping.
Bug: v8:6704
Change-Id: I5da60590c9a197eae96625a12720f6818b8c598a
Reviewed-on: https://chromium-review.googlesource.com/620452
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47430}
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}
The MSVC2017 build of Chrome fais with the following message:
c:\src\chrome\src\out\debug\gen\base\trace_event\common\../../../../../../v8/src/wasm/wasm-js.cc(76): error C2872: 'byte': ambiguous symbol
c:\src\chrome\src\out\debug\gen\base\trace_event\common\../../../../../../v8/src/wasm/wasm-js.cc(25): note: could be 'uint8_t byte'
C:\src\chrome\src\v8\src/globals.h(141): note: or 'v8::internal::byte'
Bug: chromium:683729
Change-Id: Icbc25cd1296d19b8c3942c5d968434ec03707c2f
Reviewed-on: https://chromium-review.googlesource.com/617405
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47428}
This reverts commit 0d51a2596a.
Reason for revert: Bot is broken; makes no sense to run the experiment now.
Original change's description:
> [parser] FLAG_aggressive_lazy_functions = true for a test run.
>
> Just to get the RuntimeCallstats data. To be reverted soon.
>
> BUG=v8:5516
> NOTREECHECKS=true
>
> Change-Id: I4bb436900a79bb383bf8132002a129b601efdfe3
> Reviewed-on: https://chromium-review.googlesource.com/618987
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47416}
TBR=adamk@chromium.org,machenbach@chromium.org,marja@chromium.org
Change-Id: I8506ae7e1e16a4d0b320a486f743c01f7f82e0f2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5516
Reviewed-on: https://chromium-review.googlesource.com/620749
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47425}
In LoadElimination, don't consider two fields as potentially
aliasing if they have different names.
This gives another 5% boost on the Octane/DeltaBlue benchmark,
since the redundant loads and checks on the elms of the
OrderedCollection can be properly eliminated in the chainTest.
Bug: v8:5267
Change-Id: Id2dbb8cac02f9c95a85e5cc8acac3f66b679fd06
Reviewed-on: https://chromium-review.googlesource.com/620727
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47424}
The name of the histogram is V8.GCIncrementalMarkingSum.
Bug: chromium:756592
Change-Id: Ib073e846054550cce8558a3a577a0451e3182407
Reviewed-on: https://chromium-review.googlesource.com/618877
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47422}
Fix MaxIndex in test-gap-resolver.cc so that the above check doesn't
fire.
Change-Id: I6588800281d797f3f8b33ced4c1b03315196fe44
Reviewed-on: https://chromium-review.googlesource.com/618809
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#47421}
This CL is a precursor to the callback-based enumeration of frame summaries.
It removes the reliance of FrameInspector on having a cached copy of the
FrameSummary, instead unpacking it to instance variables so that clients
of FrameInspector do not need to get information from two sources
(the FrameSummary and the FrameInspector itself).
R=yangguo@chromium.org
Bug:
Change-Id: Ib388566c2e1a1147ee0a581323932982a29ae4ff
Reviewed-on: https://chromium-review.googlesource.com/618334
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47420}
This is a followup to moving the ModuleEnv to the compiler directory and
making it immutable.
R=mtrofin@chromium.org, ahaas@chromium.org
Bug:
Change-Id: I0f5ec1b697bdcfad0b4dc2bca577cc0f40de8dc0
Reviewed-on: https://chromium-review.googlesource.com/616762
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47419}
This CL (finally) makes the contract between the compiler and the module
environment clear. In order to compile a function, the caller must provide
an instance of the compiler::ModuleEnv struct, which contains references
to code, function and signature tables, memory start, etc.
R=mtrofin@chromium.org,ahaas@chromium.org
Bug:
Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
Reviewed-on: https://chromium-review.googlesource.com/613880
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47418}
The MapGuard node sits in the effect chain as a hint for other
optimization passes that a certain value has a certain (set of)
map(s) guarded by checks on the control chain. This is useful
to learn from explicit control flow inserted for polymorphic
property accesses, and then used as part of the polymorphic
inlining.
This change improves the score on the Octane/DeltaBlue benchmark
by around 7-8% and the score on the Octane/Richards benchmark by
like 3% on average.
Bug: v8:5267
Change-Id: Id0b0b2c72e6a9342d5750a0d62cf6be6fb8c5916
Also-By: jarin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/620586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47417}
Just to get the RuntimeCallstats data. To be reverted soon.
BUG=v8:5516
NOTREECHECKS=true
Change-Id: I4bb436900a79bb383bf8132002a129b601efdfe3
Reviewed-on: https://chromium-review.googlesource.com/618987
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47416}
The race happens during evacuation when multiple threads access the
main space capacity to check CanExpandOldGeneration.
Bug: chromium:694255
Change-Id: I63dbb71cc3a894f85ee11411a5dc01d53daefa11
Reviewed-on: https://chromium-review.googlesource.com/618876
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47414}
Some preperatory refactoring to allow observation of inline allocations
from Old Space.
BUG=chromium:633920
Change-Id: Ia1232591860729fcd8942d816aa454171d3aec33
Reviewed-on: https://chromium-review.googlesource.com/617923
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#47413}
This also starts black allocation earlier if concurrent marking compile
time flag is on.
Bug: chromium:694255
Change-Id: I73c02676e5149fae10e5f9301ad585926e223a1d
Reviewed-on: https://chromium-review.googlesource.com/618893
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47412}
This patch changes how space size and capacity are updated in GC:
- space capacity changes only when a page added/removed from the space.
- space size is reset to zero before sweeping and incremented by
page->live_bytes_count_ for each to-be-swept page.
- space size is refined after sweeping using the accurate
page->allocated_bytes counter produces by the sweeper.
Invariants:
1. space.capacity = sum [page.size | for page in space].
2. After marking, before sweeping:
a) space.size = sum [page.live_bytes_count | for page in space].
3. After sweeping, before marking ends:
a) space.size = sum [page.allocated_bytes | for page in space].
b) page.allocated_bytes >= (sum [object.size | for object in page] +
page.linear_allocation_area).
c) page.area_size = (page.allocated_bytes + page.wasted_memory +
sum [free_list_entry.size | for free_list_entry in page].
3.b becomes equality if the mutator is not doing array trimming,
object slack tracking during sweeping.
Bug: chromium:694255
Change-Id: Ic8d16a8171187a113fee2df8bf3c2a4c5e77bc08
Reviewed-on: https://chromium-review.googlesource.com/618889
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47409}
There is no need to add speed-bumps for incremental marking purposes
for allocations from CompactionSpaces. This path was getting reached
for Parallel Scavenges.
Bug:
Change-Id: I1f0f315549206bc86f8c48e202c29c18d212369b
Reviewed-on: https://chromium-review.googlesource.com/617920
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#47408}
The bug was that we didn't track using await as a class name inside
arrow function formal parameters, and hence didn't recognize the error
in this case:
async(x = class await {}) => {}
BUG=v8:6714
Change-Id: Iabe6c947a4f621fb72361671d77f4765ba1a9578
Reviewed-on: https://chromium-review.googlesource.com/616776
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47407}
Before this patch, the parser mixed mixed "Null" and "Empty" as names
for null placeholder instances in ParserBase. Confusingly, those meant
different things in case of Statements.
This patch uses "Null" anywhere the meaning is "== nullptr" in the Parser.
It also makes use of std::nullptr_t and templatized IsNull() methods to
reduce the amount of boilerplate needed in both the Parser and PreParser.
Change-Id: I1451ba56d1a56466beb7e0c91dcf8e2bb7084413
Reviewed-on: https://chromium-review.googlesource.com/618167
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47406}
This improves delta blue by about >5%. Unfortunately, this still does not help load
and check elimination because we do not learn maps from control flow.
Change-Id: I49a97dbc40576b9bc80c87ec2b459e37ba9b4440
Bug: v8:5267
Reviewed-on: https://chromium-review.googlesource.com/618328
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47405}
This patch handles C-style, as well as for-in/of loops. for-await loops
will be changed in a followup.
Bug: v8:6724
Change-Id: I264b8c2d41c0318e796839bf204f7d77b6d24dd8
Reviewed-on: https://chromium-review.googlesource.com/617410
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47404}
Move the desugaring into BytecodeGenerator per TODOs.
BUG=v8:6472
R=tebbi@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org
Change-Id: Ic482bee18d6e6fe73de4c5f9abaf4feda7be2dd5
Reviewed-on: https://chromium-review.googlesource.com/550396
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47403}
Have asm.js instantiate failures tail call the function object again, which
has been reset to the CompileLazy builtin, rather than explicitly calling
the CompileLazy runtime function. This ensures that we call any optimized
code or respect the optimization marker on the feedback vector, and can
introduce DCHECKS in Compiler::Compile to this effect.
Change-Id: I69a1de006c4da8f667a3e8ae8cf69ecf241dae9a
Reviewed-on: https://chromium-review.googlesource.com/618714
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47402}
Make it consistent so that registers in all architecture have a member
function called `bit()`.
Bug:
Change-Id: Ie6323f81d4ecab1557259a43a30100d8da8b35f1
Reviewed-on: https://chromium-review.googlesource.com/618872
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47401}
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 CL introduces 6 tests that verify that the effects of a grow_memory
instruction executed inside a function are visible also from the caller of
the function.
The tests verify that:
* the current_memory instruction returns the correct value after
returning from a function that grew memory;
* accessing a memory page that has been created inside a function does
not trap in the caller;
* when a function grows the memory and then store something in the grown
memory, the caller always reads from the grown memory. This checks that
the memory start address gets updated in the caller (the memory buffer
could in fact be relocated by the grow_memory instruction).
These tests are implemented for direct and indirect function calls.
R=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Iac8db0fa7a6dd6f530e090af5423fc165d87e863
Reviewed-on: https://chromium-review.googlesource.com/616150
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47398}
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}
The WASM spec maximum memory size is higher than internal V8 maximum object
size. When a memory object grows above this limit (and only in that case), we
should signal an error.
This worked for not-exported memory; however when growing exported memory, the
code was comparing the V8 memory limit with the maximum number of pages defined
in the module, instead of the current number of pages + the number of new
required pages. This lead to signaling errors even when growing exported memory
below the V8 limit if the maximum number of pages specified in the module was
higher than the V8 limit.
GrowMemoryBuffer already checks that we do not grow a memory buffer past the
maximum size specified as parameter, so we can pass it the minimum between the
the V8 limit and the maximum number of pages specified in the module.
This CL introduces a test in test/mjsunit/wasm/import-memory.js that triggers
the problematic path and a patch to fix it.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I5a8da420418b394d61e1ba3cdf4408c3c09e61b6
Reviewed-on: https://chromium-review.googlesource.com/600217
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47395}
