We now only cache Variable* in entry_point->variables_ so there's no point in
looking at all variables_ in the entire chain.
Change-Id: I3d1f389a9ad7d790d2e778a72cd5f7fc47880233
Reviewed-on: https://chromium-review.googlesource.com/c/1340245
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57574}
For short inputs (<= size of the type we want to generate), we fell back
to just generating constants. This CL changes that to only fall back to
constants once a single byte remains, and adds options to use constants
already before that.
R=ahaas@chromium.org
Bug: v8:894307
Change-Id: Ic4bf05d06090f52b67de2b322a9d5dcab6bbbe39
Reviewed-on: https://chromium-review.googlesource.com/c/1337739
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57573}
This CL implements an assembly order optimization that moves blocks
that end a loop with an unconditional backedge to the beginning of
the loop, saving a branch.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867
Reviewed-on: https://chromium-review.googlesource.com/c/1335944
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57572}
This adds a new C++ API method
```cpp
Local<Object> Object::New(
Isolate* isolate,
Local<Value> prototype_or_null,
Local<Name>* keys,
Local<Value>* values,
size_t size);
```
which is similar to the `Object.create()` builtin exposed by JavaScript.
This new API is supposed to be used by the `http2` (in Node.js) to speed
up the creation of the HTTP header object.
Bug: v8:8422
Change-Id: I9910e88de0af2cbd8ce8a1d6cb6caa9451fb8cb4
Design-Document: http://bit.ly/v8-fast-object-create-cpp
Reviewed-on: https://chromium-review.googlesource.com/c/1337569
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57570}
With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
In order to prevent instrumented bytecode from being flushed while the function is
being debugged, hold onto the instrumented bytecode strongly.
BUG=v8:8395
Change-Id: Ie346732b77833afa0595a84a4956295e50855392
Reviewed-on: https://chromium-review.googlesource.com/c/1312849
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57569}
This fixes building with 'v8_enable_trace_ignition = true'.
Change-Id: I991b3eaba2e1a50fe9f08ae5dec765c8257a5c26
Reviewed-on: https://chromium-review.googlesource.com/c/1340039
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57567}
This marks the InterpreterEntryTrampoline as isolate-independent. With
this change, all builtins are now embedded.
Slight changes were needed to how we deopt into the trampoline. We now
store the entry address within the Interpreter class instead of
embedding the builtin code target.
Bug: v8:7777
Change-Id: If781bf6f06cb2efbab1369ece757f04c343a1b38
Reviewed-on: https://chromium-review.googlesource.com/c/1337734
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57563}
This pulls both classes into a dedicated file. InstructionStream may
be removed in a follow-up.
Tbr: mlippautz@chromium.org
Bug: v8:6666
Change-Id: Ibd374eba25cebf7495390ec13f6b4aeac5e1dc01
Reviewed-on: https://chromium-review.googlesource.com/c/1337738
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57562}
All C++ functions called directly from generated code must have
a predictable ABI. We ensure that by requiring their return and
argument types to be scalars -- in particular, they must not be
non-pointer ObjectPtr or ObjectSlot types, which is easy to get
wrong and difficult to debug. This patch adds compile-time type
checks enforcing the requirement to the macro used for creating
ExternalReferences for functions.
Bug: v8:3770
Change-Id: I442cf25e2f72b7ea84d4a50c9c665b187b179ca0
Reviewed-on: https://chromium-review.googlesource.com/c/1334974
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57560}
This reverts commit 9c91b6877a.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm%20GC%20Stress/8864
Original change's description:
> [turbofan] Use feedback when reducing global loads/stores.
>
> We already record the script context location or the property cell
> as feedback of the global load/store IC, so Turbofan doesn't need
> to do the lookups again.
>
> Change-Id: I6cbd2937de344729cd8e146b4ff85ddf3de6a56e
> Reviewed-on: https://chromium-review.googlesource.com/c/1335691
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57555}
TBR=neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: I99d72075e01348733fecdffc6b5572b96eb577b4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1339860
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57559}
This is an experimental change that may help mitigate the issue.
TBR=machenbach@chromium.org
No-Try: true
No-Tree-Checks: true
Bug: chromium:893593
Change-Id: Idf15a63006c2c7ba2c31482e5103b2a0b1d64510
Reviewed-on: https://chromium-review.googlesource.com/c/1339401
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57558}
This is an experimental change that may help mitigate the issue.
TBR=machenbach@chromium.org
No-Try: true
No-Tree-Checks: true
Bug: chromium:893593
Change-Id: Ideb74a83b9937dbe917e8c7c93305d9824b48a93
Reviewed-on: https://chromium-review.googlesource.com/c/1339419
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57556}
We already record the script context location or the property cell
as feedback of the global load/store IC, so Turbofan doesn't need
to do the lookups again.
Change-Id: I6cbd2937de344729cd8e146b4ff85ddf3de6a56e
Reviewed-on: https://chromium-review.googlesource.com/c/1335691
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57555}
On MIPS and MIPS64 build began to fail after this commit:
01079cb82f.
Change-Id: Ib967fc0d17ce1d10fdfa97d541ce9e761508593f
Reviewed-on: https://chromium-review.googlesource.com/c/1337741
Reviewed-by: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57554}
With just five cache registers, Liftoff can run out of memory on a
64bit shift. This CL solves this by using a parallel register move and
pinning less registers.
R=ahaas@chromium.org
Bug: chromium:894307
Change-Id: I91ed0fee00ceb452841e5d1bb10905be6702dcce
Reviewed-on: https://chromium-review.googlesource.com/c/1337580
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57552}
In WasmCode::LogCode we allocate handles, but not all callers of LogCode
open a HandleScope. Since the handles do not escape LogCode, we can just
open a Handlescope in the function.
R=herhut@chromium.org
Bug: v8:8461
Change-Id: I2031b467f976a9af6f541b60af245573f33d9676
Reviewed-on: https://chromium-review.googlesource.com/c/1337736
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57550}
Emit Dlsa/Lsa only on revision 6 or when MSA is supported. Since we
support MSA only on r6, it is the only thing that is checked.
Added check if shift of Dlsa/Lsa is in range 0<shift<=31
Change-Id: Ic3902fcccc1a2e3ecc5f550ea3b7980bd2bb4c27
Reviewed-on: https://chromium-review.googlesource.com/c/1337581
Reviewed-by: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57549}
V8 supports a mechanism to generate better profiling information for
ticks in bytecode execution. Usually, these would find the IET but would
not know which JS function is currently being executed. With
--interpreted_frames_native_stack, we create a dedicated copy of the
IET for each JS function, which the profiler can use the infer the
current function.
This mechanism doesn't work when IET is embedded. But JIT-less V8 will
require all builtins to be embedded.
This CL implements a workaround that should keep all configuration
happy: We keep a full copy of IET on the root list for sole purpose of
using it as a template to create copies for profiling later on. The
'real' IET builtin itself can be embedded in a follow-up CL.
Change-Id: Iaf1629708f0e41c3683979245019fbd3e3153c97
Reviewed-on: https://chromium-review.googlesource.com/c/1335700
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57548}
This test is only flaky because the js code being profiled causes a
'fast-c-call' which is a call from JS to C without an exit frame.
The profiler stumbles on these and reads the stack of C++ frames when
it shouldn't, causing ASAN errors. This is not actually related to
the multiple isolates, so I'm changing the test to profile different
JS code that does not cause these types of calls. There is already a
test for fast-c-calls - NativeFrameStackTrace (which currently fails).
Bug: v8:8464
Change-Id: I32818f0894e5680cf5a39779a2779eda36dfe9f1
Reviewed-on: https://chromium-review.googlesource.com/c/1337571
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57547}
This is a reland of 0b13f0f517
Original change's description:
> [snapshot] Emit the embedded blob as assembly instead of inline assembly
>
> The motivation behind this is that MSVC doesn't support inline assembly
> on x64. Emitting the embedded blob as a plain assembly file will give us
> MSVC support (and possibly faster compilation times as a side-effect).
>
> Bug: v8:6666,v8:8349
> Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
> Reviewed-on: https://chromium-review.googlesource.com/c/1329205
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57524}
Tbr: yangguo@chromium.org,mvstanton@chromium.org
Bug: v8:6666, v8:8349
Change-Id: Ib35696b60a9cd01bc2edf459c8e8d84716e3438d
Reviewed-on: https://chromium-review.googlesource.com/c/1337733
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57546}
Now that we always cache lookups through scope-info-backed scopes on the
entry-point scope-info-backed scope, we don't need additional caching
per scope-info. The one missing piece was negative lookups, but they
automatically turn into DynamicGlobals which we also cache on the entry
scope.
The one possible difference is that we don't cache across compilation,
but seems unlikely to be very beneficial. We'll keep an eye out for
regressions though.
Change-Id: I23186d2b085d2042fafa32fb3cca88f88c61074c
Reviewed-on: https://chromium-review.googlesource.com/c/1337731
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57544}
With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
In order to avoid having to recompile (and potentially stack-overflow) on
deoptimization, we explicitly add strong references to any BytecodeArray's we
might deopt into into the DeoptimizationData, as such the BytecodeArrays won't
be flushed while there is optimized code referencing it.
BUG=v8:8395
Change-Id: If3336dfa9c17b7bccafdb73752c58dfa1f14a371
Reviewed-on: https://chromium-review.googlesource.com/c/1314579
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57543}
We'll always lookup variables in the entry scope-info-backed chain through a
single entrypoint, hence we can cache any variables we create in that chain on
the entry-point's VariableMap. Otherwise we always have to redo all negative
lookups until we hit the scope that introduces it (the script scope being the
final possible scope to introduce it).
This should allow us to get rid of the ContextSlotCache as well.
Change-Id: I2dc2c9c35d69f35dab3fe3d0353aba1ac68515a5
Reviewed-on: https://chromium-review.googlesource.com/c/1337729
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57542}
This might have enabled our fuzzing to find the recent bug.
R=bmeurer@chromium.org
Bug: v8:8449
Change-Id: Iaa485061e132a9d20b995478dd9a642e2224f435
Reviewed-on: https://chromium-review.googlesource.com/c/1337588
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57541}
This is a reland of bf2f0a0227
Original change's description:
> [builtins] Support embedded builtins in nosnapshot builds
>
> This CL adds support for embedded builtins in nosnap builds by creating
> and setting an 'embedded blob' after builtin generation. Unlike
> snapshot builds, the blob is not embedded into the .text section but
> located on the C++ heap.
>
> This makes nosnap builds more consistent with mksnapshot, and allows us
> to simplify there and in serializer cctests.
>
> Complications arise from the different workflows we need to support:
>
> 1. the standard mksnapshot build process,
> 2. nosnap builds (which reuse the blob created by the first Isolate),
> 2. and tests with various complicated serialization workflows.
>
> To cover all of these cases, this CL introduces two knobs to twiddle:
>
> 1. A 'sticky' embedded blob which overrides compiled-in default
> embedded blobs at Isolate setup.
> 2. The blob lifecycle can be managed manually or through refcounting.
>
> These are described in more detail in isolate.cc.
>
> Tbr: ulan@chromium.org
> Bug: v8:6666, v8:8350
> Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
> Reviewed-on: https://chromium-review.googlesource.com/c/1310195
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57523}
Tbr: ulan@chromium.org,yangguo@chromium.org
Bug: v8:6666, v8:8350
Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738
Reviewed-on: https://chromium-review.googlesource.com/c/1337578
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57540}
We often need to create a {Vector} view of data owned by a container
like {std::vector}. The canonical way to do this is this:
Vector<T>{vec.data(), vec.size()}
This pattern is repeating information which can be deduced
automatically, like the type T.
This CL introduces a {VectorOf} helper which can construct a {Vector}
for any container providing a {data()} and {size()} accessor, and uses
it to replace the pattern above.
R=ishell@chromium.org
Bug: v8:8238
Change-Id: Ib3a11662acc82cb83f2b4afd07ba88e579d71dba
Reviewed-on: https://chromium-review.googlesource.com/c/1337584
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57538}
With Bytecode flushing, the a SharedFunctionInfo's bytecode might be flushed
while the compiler is expecting it to still exist. Rather than continually
getting the bytecode from the SFI, instead bottleneck the points where we get
BytecodeArray from SFIs and maintain an explicit strong reference to the
BytecodeArray from that point onwards to prevent flushing.
BUG=v8:8395
Change-Id: I6a18adec99402838690971eb37ee0617cdc15920
Reviewed-on: https://chromium-review.googlesource.com/c/1309763
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57536}
When one of the inputs to NumberMin or NumberMax is NaN we need to
return NaN, ignoring whatever else was passed. Specifically we cannot
lower `NumberMin(x,y)` to `(x < y) ? x : y` if `x` can be NaN. So
limit this optimization to only perform the above lowering if we
know that `x` is an OrderedNumber and `y` is a PlainNumber (or if
the difference between zeros doesn't matter, an OrderedNumber as
well).
Bug: chromium:905457
Change-Id: If05f19255e14789ab0e277e072469c40e161b85b
Reviewed-on: https://chromium-review.googlesource.com/c/1337576
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57535}
This adds flags for the upcoming JIT-less V8.
Build-time: v8_enable_jitless_mode in gn.args
Runtime: --jitless command-line flag
The build-time flag is expected to be removed as the implementation
matures.
Bug: v8:7777
Change-Id: Ieea404a14c7859a66e18175d1740d73182db9b1b
Reviewed-on: https://chromium-review.googlesource.com/c/1335559
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57533}
This fixes several problems with instanceof and constant field tracking
in the compiler:
- properly bailout on numbers and non-functions at @@hasInstance.
- deopt on changes of @@hasInstance property.
Bug: v8:8361
Change-Id: I4a1cf9e29d72076f2d37a7c703f18cb2fb8f4040
Reviewed-on: https://chromium-review.googlesource.com/c/1322449
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57532}
This reverts commit bf2f0a0227.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21753
Original change's description:
> [builtins] Support embedded builtins in nosnapshot builds
>
> This CL adds support for embedded builtins in nosnap builds by creating
> and setting an 'embedded blob' after builtin generation. Unlike
> snapshot builds, the blob is not embedded into the .text section but
> located on the C++ heap.
>
> This makes nosnap builds more consistent with mksnapshot, and allows us
> to simplify there and in serializer cctests.
>
> Complications arise from the different workflows we need to support:
>
> 1. the standard mksnapshot build process,
> 2. nosnap builds (which reuse the blob created by the first Isolate),
> 2. and tests with various complicated serialization workflows.
>
> To cover all of these cases, this CL introduces two knobs to twiddle:
>
> 1. A 'sticky' embedded blob which overrides compiled-in default
> embedded blobs at Isolate setup.
> 2. The blob lifecycle can be managed manually or through refcounting.
>
> These are described in more detail in isolate.cc.
>
> Tbr: ulan@chromium.org
> Bug: v8:6666, v8:8350
> Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
> Reviewed-on: https://chromium-review.googlesource.com/c/1310195
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57523}
TBR=ulan@chromium.org,yangguo@chromium.org,jgruber@chromium.org
Change-Id: I6e35a0cb7186fb50f1012f5c618fb8b48b24a813
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:8350
Reviewed-on: https://chromium-review.googlesource.com/c/1337577
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57529}
This reverts commit 0b13f0f517.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20debug/17373
Original change's description:
> [snapshot] Emit the embedded blob as assembly instead of inline assembly
>
> The motivation behind this is that MSVC doesn't support inline assembly
> on x64. Emitting the embedded blob as a plain assembly file will give us
> MSVC support (and possibly faster compilation times as a side-effect).
>
> Bug: v8:6666,v8:8349
> Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
> Reviewed-on: https://chromium-review.googlesource.com/c/1329205
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57524}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org
Change-Id: I35f7763f86b4de01e74827a95706b969b43af55e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:8349
Reviewed-on: https://chromium-review.googlesource.com/c/1337574
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57528}
This avoids creating an on-heap copy for interpreter entry wrappers by
directly adding the {WasmCode} into the native heap instead. It reduces
compilation time as well as useless GC pressure.
R=clemensh@chromium.org
BUG=v8:8423
Change-Id: I91a8f3fc9fe542233d8700a58585f4715eed695a
Reviewed-on: https://chromium-review.googlesource.com/c/1337570
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57527}
