Commit Graph

66814 Commits

Author SHA1 Message Date
Santiago Aboy Solanes
e16427fa6c [compiler] Unpark local heap for GraphTrimmer::TrimGraph's traces
Bug: v8:7790
Change-Id: I7900d041ff1331991d14e2766a6760b69f37622e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637230
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72172}
2021-01-19 18:04:41 +00:00
Seth Brenith
d307b61285 [torque] Allow returning pairs from builtins
This would be useful for ForInPrepare. Syntax is unchanged; Torque
should now do the right thing for builtins that return a two-element
struct. More elements than that is still not supported.

Bug: v8:7793
Change-Id: Ic315699402203aba07e906ff6e029834ec0061c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596498
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72171}
2021-01-19 18:03:12 +00:00
Zhi An Ng
a1d39bbaed [wasm-simd] Prototype i32x4.widen_i8x16_{s,u}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for the
interpreter.

This is the first instruction of its kind, a post-mvp, unary operation
that takes one immediate. Which is why there are more changes to the
decoder than usual.

Bug: v8:11297
Change-Id: Ib5c58965e0cba8d7a395b0dc57673110bc60e87c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617385
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72170}
2021-01-19 17:45:11 +00:00
Marja Hölttä
f6450b97ec Reland [super] Store home object in Context instead of JSFunction
1) Computed property keys (esp functions in them) shouldn't be inside
the object literal scope.

2) I was using an imprecise "maybe uses super" and storing it to
preparse data. This won't fly, since it pollutes sister scopes and
leads to confusion wrt whether an object literal needs a home object
or not. Made it precise (mostly cancelling changes in the original CL).

3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
this_function (which made it used) -> inconsistent scopes between
parsing and preparsing.

4) MultipleEntryBlockContextScope was messing up the accumulator

Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275

This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.

Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing

Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72169}
2021-01-19 17:05:01 +00:00
Liviu Rau
388a99e8c0 [tools] Use CAS in 'mb.py run -s'
Bug: chromium:1166989
Change-Id: I6eca7745ee4457d86ecda65a3972011899bac9c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637219
Auto-Submit: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72168}
2021-01-19 16:59:01 +00:00
Sathya Gunasekaran
b6708f7227 [unittest] Rename last to prev
`last` indicates that it's the last element of the list but in reality
this supposed to indicate the previous entry in the list. Rename this
to something more clearer.

Change-Id: I26c9a1fca02cf6b10d0447768da694d590a43932
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637229
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72167}
2021-01-19 16:54:51 +00:00
Ross McIlroy
7de37e9666 [TurboFan] Perform serialization of native context maps on background.
Moves the serialization of the initial set of maps read from the native
context from the forground serialization phase to a new background
serialization phase.

BUG=v8:7790,v8:9684

Change-Id: Id408e5c3096e832cf30106eb8fb7d65518432e06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613028
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72166}
2021-01-19 16:48:01 +00:00
Seth Brenith
a016c9fec4 [arm][arm64] Use normal fp semantics in JSEntry
On arm64, Windows Performance Recorder gets confused by the fact that fp
in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
caller frame. The expected usage of fp is documented in [1]:

  The frame pointer (x29) is required for compatibility with fast stack
  walking used by ETW and other services. It must point to the previous
  {x29, x30} pair on the stack.

In slightly more detail, the Windows function RtlWalkFrameChain is
responsible for generating stack traces during profiling with Windows
Performance Recorder, and that function relies on the rule quoted above.
Notably, it does not make any effort to read the unwinding data that one
could obtain with RtlLookupFunctionEntry. Stack walks using that data,
such as those performed by WinDbg and the cctest StackUnwindingWin64,
work fine.

It would be convenient if we could use fp in a more standard way during
JSEntry so that Windows profiling tools work correctly. (We can also
reduce JSEntry by two instructions in doing so.)

Both arm and arm64 currently put a -1 value on the stack at the location
that fp points to. This could prevent accidental access during the
epilog of JSEntry, where fp might be zero. However, we believe that this
protection is no longer necessary, and any bug that causes a read from
fp during the end of JSEntry would cause various CQ failures.

[1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160

Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72165}
2021-01-19 16:13:51 +00:00
Clemens Backes
81b3372efa [wasm] Fix tier-down test for multiple isolates
The test was explicitly tiering up or down a module, without respecting
other isolates. Thus it was failing in multi-isolate mode.
This CL removes two runtime functions which do not make sense in a
multi-isolate setting (and were only used in this one test), and
replaces them with runtime functions that mimic what enabling/disabling
the debugger domain does: As long as there is at least one isolate which
needs modules to be tiered down, we keep them tiered down.

R=thibaudm@chromium.org

Bug: v8:10359, v8:10099
Change-Id: Ia85f4ea29ba6a6bb54aca54a48fadd351121d3eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637231
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72164}
2021-01-19 16:11:01 +00:00
Clemens Backes
99fb013683 [wasm] Avoid redundant passing of the wasm engine
The engine can be retrieved from the NativeModule, hence avoid passing
it explicitly.

R=ahaas@chromium.org

Change-Id: I38f9bdb9624006da8311e57c3e53327654b6e85a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637855
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72163}
2021-01-19 15:57:01 +00:00
Georg Neis
aac9d77a87 [cleanup] Remove unused function in SharedStringAccessGuardIfNeeded
Change-Id: Ifad7bbafc8b7c7ff8cf9140b9227cb9c67370fcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637856
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72162}
2021-01-19 15:20:28 +00:00
Jakob Gruber
2d576e824d [compiler] Add a SilenceNaN helper to encapsulate pattern
The helper encapsulates the `x - x` pattern to silence NaN `x`.

Bug: v8:7519
Change-Id: Ia633272d7b7cc350c7e4db07e271e0192c68019f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637232
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72161}
2021-01-19 15:15:58 +00:00
Junliang Yan
9f94442e0d s390x: fix compilation error on typo
Change-Id: I3803e3f7916827b3b9853c8c3a3ce6806cc2daac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636054
Commit-Queue: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72160}
2021-01-19 15:04:18 +00:00
Benedikt Meurer
975ded1d3d [debug][wasm] Store debug proxy maps on native context.
This was originally proposed by yangguo@ on the original CL that
introduced this, but back then it looked easier to put the map cache
onto the global object than on the native context. However it turns out
that this is indeed quite strange and also not necessarily supported (we
got crashes from the wild indicating that the `Object::GetProperty()`
might fail on the global object). So this CL simplifies the original
design and just puts the map cache onto the native context like with do
with other context specific maps.

Fixed: chromium:1167399
Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
Change-Id: Ie16f892dd19b55b4c49e9d4829cab3c24ae64ad3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637226
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72159}
2021-01-19 14:58:38 +00:00
Clemens Backes
3ad2342415 Revert "[compiler] Emit a function-entry stack check on OSR-entry"
This reverts commit 8703c38d9a.

Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview)

Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}

TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org

Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1034322
Bug: v8:9534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72158}
2021-01-19 14:53:52 +00:00
Junliang Yan
8e93a32d3c s390x: [liftoff] implement Load function
Change-Id: I42ff5501bec10ef5230ea06d5feb9adc5be0d875
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633731
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72157}
2021-01-19 14:29:38 +00:00
Clemens Backes
2c1d99e584 [inspector] Handle isolate termination gracefully
The inspector fuzzer is terminating the isolate after two seconds. At
this point, we can be in pretty much any state, and any further JS
execution would fail.
This CL fixes an issue where we got the termination signal when creating
a context for a regexp (while installing extensions).
There might be more places that need fixing, but with this CL the linked
issue does not reproduce locally any more, so it's a step forward.

R=szuend@chromium.org, bmeurer@chromium.org

Bug: chromium:1166549
Change-Id: I33b48205b71877aca6cfe5267f353fa899bfa05c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636153
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72156}
2021-01-19 14:22:41 +00:00
Michael Lippautz
852294fc4a heap,cppgc: Support for termination GC
Termination GCs are used to destroy remaining C++ object on the
managed heap to free potential off-heap memory. This is important for
gracefully shutting down workers.

Drive-by: Add guard prohibiting recursive sweeping calls on the
  mutator thread.

Bug: chromium:1056170
Change-Id: I02ea3b632d38f5beab18cc8f077cf717ed877909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2631504
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72155}
2021-01-19 14:08:18 +00:00
Milad Fa
37304af710 S390 [wasm-simd]: prototype i64x2 widen i32x4
Bug: v8:10972
Change-Id: Id7b17ad54f0a6a1a8b3eb04bb81b2ec94bca921b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2635796
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72154}
2021-01-19 13:58:08 +00:00
Jakob Gruber
8703c38d9a [compiler] Emit a function-entry stack check on OSR-entry
This CL extends the smarter function-entry stack check logic (see
v8:9534) to OSR'd code. These smarter stack checks prevent
overflowing the stack during deoptimization.

The challenge for both function-entry (FE) and OSR-entry (OE) stack
checks is that there is no dedicated physical StackCheck to
deoptimize into. For more context: the physical StackCheck bytecode
was removed in crrev.com/c/1914218.

FE stack checks solve this by using a marker bailout id to signify
a deopt bytecode offset before the first bytecode.

In this CL, OE stack checks take a similar approach by using the
OSR'd loop's JumpLoop bytecode, which is conceptually immediately
before the OSR'd loop header.

When a stack overflow at an OE stack check occurs: %StackGuard
may cause a lazy deopt on return to the optimized OSR code,
causing re-execution of the JumpLoop handler in the
InterpreterEnterBytecodeAdvance builtin, ultimately continuing
execution the interpreter at the first bytecode of the OSR'd loop
header.

Bug: chromium:1034322, v8:9534
Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72153}
2021-01-19 13:26:18 +00:00
Milad Fa
d044486855 PPC [wasm-simd]: prototype i64x2 widen i32x4
Bug: v8:10972
Change-Id: I76d795c1f4cf0fc39ca4b4f4ea72c8e817c17da5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632699
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72152}
2021-01-19 13:24:23 +00:00
Sathya Gunasekaran
7819b1b579 [runtime] Simplify LookupIterator::UpdateProtector
There's no need for these extra protector checks as the actual checks
are now fast -- we don't have to compare against function objects in
every context but instead just do a very quick instance type check.

Bug: v8:11256
Change-Id: I40cdf40c8c85e39354bcbd32a7808cd083c8e45b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2598586
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72151}
2021-01-19 13:22:49 +00:00
Andreas Haas
58a13f118e [wasm] Main thread participates in debugging recompilation
R=clemensb@chromium.org

Bug: v8:11319
Change-Id: If24b1ba929bce2e4268a794930c325aaebcfa556
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637222
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72150}
2021-01-19 13:17:08 +00:00
Ross McIlroy
b967c0d138 [Turboprop] Avoid using SAME_INPUT_OUTPUT registers for USED_AT_END inputs.
If a register is used for both input and output by a SAME_INPUT_OUTPUT
operand, then it represents a different virtual register for the end
use-position of an instruction (since that will become the output's
virtual register). It therefore can't be used to represent the input
virtual register for any input operands that are USED_AT_END.

BUG=chromium:1163715,v8:9684

Change-Id: I8dc0008ba81d5f1d0e38091b6dc013725c62b1b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632700
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72149}
2021-01-19 12:36:18 +00:00
Z Nguyen-Huu
3bb899eb8a [v8windbg] Generate debug macros files
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI

Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.

Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).

Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}
2021-01-19 12:07:38 +00:00
Paolo Severini
6ada6a90ee Reland "Faster JS-to-Wasm calls"
This is a reland of 860fcb1bd2

- Disabled the tests for this feature in V8-lite mode (the original
change broke V8-lite tests)
- Also modified test console-profile-wasm.js that was brittle with this
change because it assumed that there was always a JS-to-Wasm wrapper
but this is not the case when the TurboFan compilation completes before
the Liftoff-compiled code starts to run.

More changes in Patchset 8:

- Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
into a new phase, wasm-inlining that reuses the JSInliner reducer.
The doc
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
describes the new logic.

- Fixed a couple of small issues in wasm_compiler.cc to make sure that
the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
this should solve the problem we had inlining the calls in functions
that can throw exception.


Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
> Bug: v8:11092
> Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#71824}

Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72147}
2021-01-19 11:54:38 +00:00
Sathya Gunasekaran
624030e975 [runtime] Add new instance types for constructor functions
This will allow us optimize the protector cell checks in the fast path
from checking against the function object in every context to just
doing a range check against the instance type.

This patch adds new instance types for constructor functions that
require such protector cell checks.

Bug: v8:11256
Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72146}
2021-01-19 11:16:18 +00:00
Jakob Gruber
47135e0368 [compiler] Don't iterate past end of StateValuesAccess iterator
StateValuesAccess iterates over actual (non-adapted) arguments, thus
we must be careful not to iterate past their end when handling rest
args and advancing through the initial non-rest-args.

Tbr: neis@chromium.org
Bug: chromium:1167709,chromium:1166136
Change-Id: If506050a5518f394e0dcdbf39840b99923d4cbae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637213
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72145}
2021-01-19 09:46:13 +00:00
Andreas Haas
722050d8cd [wasm] Add compilation id for trace events to compile jobs
For asynchronous compilation, the beginning and end of compilation are
marked with different trace events. To allow to connect these events, a
compilation id is added to the start and end events. Note that the
compilation id is not added to all trace events to avoid bloating
traces. Ids may be added later to these events if necessary.

R=clemensb@chromium.org

Bug: chromium:1084929
Change-Id: I36ad598d27dea355fcca8992534c91e5a880fdaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629274
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72144}
2021-01-19 09:45:08 +00:00
Michael Achenbach
14f7c4c0f0 Revert "[wasm][mac][arm64] Enable OOB trap handler"
This reverts commit a80d51d488.

Reason for revert: Breaks:
https://ci.chromium.org/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/2042

Original change's description:
> [wasm][mac][arm64] Enable OOB trap handler
>
> R=​ahaas@chromium.org,mark@chromium.org,mseaborn@chromium.org
>
> Bug: v8:11098
> Change-Id: Ic4eb02a96805e49da71f301269567a6e0ac1b843
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519555
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72136}

TBR=mseaborn@chromium.org,ahaas@chromium.org,mark@chromium.org,ishell@chromium.org,zhin@chromium.org,thibaudm@chromium.org

Change-Id: I73d868f044f3c362e4a6d65533fccbdb49c51cd3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11098
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637216
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72143}
2021-01-19 08:47:59 +00:00
Maya Lekova
e3dbd69fea Revert "[super] Store home object in Context instead of JSFunction"
This reverts commit 4d5b878b61.

Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263

Original change's description:
> [super] Store home object in Context instead of JSFunction
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237
> Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72137}

TBR=marja@chromium.org,leszeks@chromium.org

Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
2021-01-19 08:38:40 +00:00
Junliang Yan
7d112848c0 s390x: Create LE version of Load
Change-Id: I4bb964bee86248b7990e69ac458431c2a489bcd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633730
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72141}
2021-01-18 17:10:56 +00:00
Dan Elphick
553def5ffa [build] Add header for externally-visible defines
Adds a v8-gn.h file containing defines that are used in the
externally-visible headers files like v8.h. This must be included by
include/v8config.h which includes it if the GN flag
v8_generate_external_defines_header is on. (Currently off by default).

To enable the v8config.h file to be included without the other v8
headers (as required by cppgc), this moves it into its own header set
which sets up the include path correctly.

Also updates some headers to ensure v8config.h is included before using
externally-visible defines.

Bug: v8:11292
Change-Id: I5be634f4adfbef144bf684071461d64f1cb30899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608212
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72140}
2021-01-18 16:57:26 +00:00
Andreas Haas
18534a4214 [wasm][liftoff] Fix index in the initialization of locals
There was a bug that only the last local with a reference type got
initialized to null, all other locals kept the initial value of 0. This
CL fixes this bug.

Additionally this CL optimizes the code slightly. Before this CL, the
null reference was loaded from the instance for every local with
reference type. Now the null reference is cached after the first load
and then used for all other locals.

R=thibaudm@chromium.org

Bug: chromium:1167587
Change-Id: Ic11fc76b650e6daa029491154744fc132778f70d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632695
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72139}
2021-01-18 15:52:26 +00:00
Seth Brenith
e3f8b5dba5 [heap-profiler][torque] Report types of all internal objects
Heap-profiler changes:

Currently, a whole lot of types are all reported as just "system" in
heap snapshots. With this change, we can use Torque-generated macro
lists to easily report type names such as "system / BytecodeArray".
Those objects still show up in a single category named "(system)" in the
dev tools UI, so they don't clutter the output. For V8 developers or
anybody who is interested in an extra-detailed view, this change also
includes a runtime flag that instructs V8 to upgrade nodes of type
kHidden to type kNative. After a snapshot is collected with this flag
enabled, the dev tools UI then shows each internal object type
separately.

Torque changes:

Currently, Torque emits several macro lists containing pairs of
(ClassName, CLASS_NAME_TYPE) which can be used to associate instance
types with Torque class names. However, some Torque classes are not
included in any of these three lists. In cases like the heap profiler,
it would be nice to easily generate a complete list including every
instance type, so this CL includes two changes:

- Include classes in TORQUE_INSTANCE_CHECKERS_MULTIPLE_FULLY_DEFINED
  even if they're not marked `extern`. I'm not sure what exactly we
  were hoping to accomplish in filtering by extern-ness, but it's
  simpler not to and slightly reduces clutter in a couple of files that
  use that macro list.
- Add a fourth macro list for the previously-ignored category: classes
  which have their own instance type (are not `abstract`), and have
  subtypes, but do not have their fields defined in Torque. This list
  contains just a single item (HashTable), but I like the consistency of
  generating the full set of lists.

Change-Id: Ib24953e12ed13ce353206bbec23a52d8f684dfcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610172
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72138}
2021-01-18 15:49:46 +00:00
Marja Hölttä
4d5b878b61 [super] Store home object in Context instead of JSFunction
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.

Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing

Bug: v8:9237
Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72137}
2021-01-18 15:47:06 +00:00
Thibaud Michaud
a80d51d488 [wasm][mac][arm64] Enable OOB trap handler
R=ahaas@chromium.org,mark@chromium.org,mseaborn@chromium.org

Bug: v8:11098
Change-Id: Ic4eb02a96805e49da71f301269567a6e0ac1b843
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519555
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72136}
2021-01-18 15:32:56 +00:00
Junliang Yan
c92aa9e17b s390x: [liftoff] implement Load/StoreTaggedPointer
Change-Id: Ia8e8600cabb7e317befca480e734915239e10f69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2634828
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72135}
2021-01-18 15:20:16 +00:00
Nico Hartmann
2800584800 Reland "[TurboFan] Move SFI and BytecodeArray to kNeverSerialized"
This reverts commit ff606a06b1.

This fix makes a handle persistent that was missing in the original CL.

Bug: v8:7790, chromium:1158322
Change-Id: I53079f5c32523313cff76130d2a40c3de5bb0638
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629270
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72134}
2021-01-18 14:52:41 +00:00
Victor Gomes
574ac5d626 [cleanup] Remove arguments adaptor code
Removes:
- v8_disable_arguments_adaptor GN flag
- ArgumentsAdaptorTrampoline
- ArgumentsAdaptorFrame class

Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72133}
2021-01-18 14:51:36 +00:00
Clemens Backes
7d167bde93 [wasm][memory64] Fix typing of memory.size
memory.size returns in i64 if memory64 is enabled.
This CL fixes typing and adds a decoder test. Execution will be tested
and fixed in a follow-up CL.

R=manoskouk@chromium.org

Bug: v8:10949
Change-Id: I15818a6273b579d0faacec7f77dc813ae9ba218f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632593
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72132}
2021-01-18 14:05:13 +00:00
Clemens Backes
5147463590 [wasm][memory64] Implement 64-bit init expressions
For memory64, the init expressions for data segments provide a 64-bit
value. This CL adds a new {EvalUint64InitExpr} function alongside
{EvalUint32InitExpr}. It supports i64.const and global.get operations.

R=manoskouk@chromium.org

Bug: v8:10949
Change-Id: I58acbb28acb8771a0947f9d5df1c14e6ca0f79cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632589
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72131}
2021-01-18 12:47:43 +00:00
Sami Kyostila
c65456bfa4 tracing: Initialize track events conditionally
If V8 is running in a context where Perfetto hasn't been initialized
(e.g., as part of mksnapshot), don't try to initialize track events
either.

Since perfetto::Tracing::IsInitialized() was only added recently, we
also roll Perfetto to the latest revision. This also requires updating
the proto_library GN template together with the underlying libprotobuf
dependency.

Bug: chromium:1006541
Change-Id: Icec626b7ed78264a81f1a80d73d60be3bde0d908
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632590
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72130}
2021-01-18 12:39:03 +00:00
Ross McIlroy
a75b129acb [TurboFan] Only serialize JSFunction feedback and code if needed.
The feedback_vector/cell and code fields of a JSFunctionRef are only
used when generating code for the function (e.g., for the function
being optimized or inlined functions). This CL explicitly serializes
these fields only when the function will be used for codegen, otherwise
avoiding their serialization.

BUG=v8:7790,v8:9684

Change-Id: If76bc0b77e51aa10517699e0a9198358fe77f009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617083
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72129}
2021-01-18 12:02:35 +00:00
Mythri A
d7f767e16c [turboprop][runtime-profiler] Fix a bug that disabled OSR
This cl: https://chromium-review.googlesource.com/c/v8/v8/+/2632588
introduced a bug by bailing out early if we have top tier code early.
However, we still need to check if the frame is still interpreted
so that we could OSR. The early bailout isn't correct and also the
DCHECK isn't correct. This cl removes both.

Bug: chromium:1167638, v8:9684
Change-Id: I5a4aa406b05b6cbb5f98b63e015298c5b45160eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632696
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72128}
2021-01-18 11:08:10 +00:00
Clemens Backes
589677bcec [wasm][liftoff] Check for unexpected bailout
We are working on getting Liftoff feature complete. Eventually, bailout
should only happen if experimental features are enabled. Until we are
there, we also need to allow some more bailouts, which should be removed
in the near future.

This CL adds a check for expected bailout reasons. The new function
serves as a burndown list of issues to be fixed.

Drive-by: Make some methods constexpr such that they can be used in
static assertions.

R=ahaas@chromium.org

Change-Id: I5d3cd8f49a30d01f89ac6cf5321e1314b63eba40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629513
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72127}
2021-01-18 10:30:41 +00:00
Jakob Gruber
0ef84f9930 [compiler] Use StateValuesAccess to access frame state parameters
FrameState parameters must not be iterated directly since parameters
can be encoded into StateValues (i.e. parameter i is not necessarily
InputAt(i)). Instead, they should be accessed through the
StateValuesAccess helper class.

One example:

 82: StateValues[sparse:^^^^^^](81, 31, 32, 33, 34, 35)
  81: StateValues[sparse:^^^^^^^^](110, 24, 25, 26, 27, 28, 29, 30)
  31: NumberConstant[8]
  32: NumberConstant[9]
  33: NumberConstant[10]
  34: NumberConstant[11]
  35: NumberConstant[13]

Here, node 81 holds multiple parameters. These are properly iterated
by the StateValuesAccess class.

Bug: chromium:1166136
Change-Id: I12725f83994e1c05571bcba153ff45154b16d93f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625879
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72126}
2021-01-18 07:56:20 +00:00
v8-ci-autoroll-builder
8ba6fb7fbc Update V8 DEPS.
Rolling v8/build: 3ecdb5e..43dd249

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f46e9e7..cf567b6

TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

Change-Id: I22b2eb5734c9578289d1700b1fae88f2c338d3e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2635361
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#72125}
2021-01-18 03:50:50 +00:00
v8-ci-autoroll-builder
7480994d41 Update V8 DEPS.
Rolling v8/build: 670a905..3ecdb5e

Rolling v8/buildtools: 235cfe4..c38b5ab

Rolling v8/buildtools/linux64: git_revision:595e3be7c8381d4eeefce62a63ec12bae9ce5140..git_revision:d62642c920e6a0d1756316d225a90fd6faa9e21e

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b2af2da..f46e9e7

Rolling v8/third_party/depot_tools: 091f5ac..dabd965

TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

Change-Id: Ib0c53b119f960f4d8d41d7bd1b4355ea82b0b009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632878
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#72124}
2021-01-16 03:42:08 +00:00
Santiago Aboy Solanes
c92572ba2f Revert "[objects] Remove MakeExternal case for uncached internal strings"
This reverts commit 3a6f75ac94.

Reason for revert: performance regressions https://bugs.chromium.org/p/chromium/issues/detail?id=1163063

Original change's description:
> [objects] Remove MakeExternal case for uncached internal strings
>
> Concurrently accessing internal external uncached strings is not
> thread-safe. We are removing a case where we can make such a string
> through MakeExternal.
>
> Bug: v8:7790
> Change-Id: I958062c15cf40ccc330600bb572de98620866e54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71573}

TBR=leszeks@chromium.org,solanes@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:7790
Change-Id: I5dcc734869c3c921eacd89426309141127a85f47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633547
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72123}
2021-01-15 20:57:04 +00:00