Commit Graph

77 Commits

Author SHA1 Message Date
Marja Hölttä
2eb253764f [rab/gsab] Re-enable serializing flags with ValueSerializer
Also:
- Refactor the ValueSerializer tests using raw data, so that we test all
valid versions for each test (not only one hard-coded one)
- Mark some tests as backwards compatibility tests, to make it less
likely that somebody updates them not realizing they are backwards
compatibility tests.

Bug: v8:11111, v8:12532
Change-Id: I670849de07742c8d442249ef4f013781e4ee9255
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386802
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78681}
2022-01-19 12:45:39 +00:00
Andreas Haas
53018f4eb4 [wasm] Throw an exception when wasm memory allocation fails
V8 crashed with a FATAL when memory allocation during instantiation
failed. With this CL, a RangeError is thrown instead.

This is not the only possible OOM that can happen during the startup of
a WebAssembly app, but since the allocation of WebAssembly memory is
among the biggest allocations, this change may already prevent several
crashes.

R=clemensb@chromium.org

Bug: chromium:1268898
Change-Id: I9376830ba2fe9df62b5595b6b19c92e35a75dfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380586
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78569}
2022-01-11 19:52:47 +00:00
Austin Sullivan
60a35f6029 Remove trailing serialization tag in test
This should have been updated in https://crrev.com/c/3370408

Bug: chromium:1284506
Change-Id: Ie44d80b507c9a798ce6f4776672270f9d4b12195
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3371463
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78519}
2022-01-07 20:09:25 +00:00
Victor Costan
679c317efb Restore typed array serialization format.
https://crrev.com/c/3297708 changed the serialization format for typed
arrays without bumping the format version. As a consequence, builds that
include that CL fail to deserialize typed arrays serialized by previous
V8 versions.

This CL reverts the serialization format change, and does minimal test
changes to reflect the revert. https://crbug.com/v8/12532 tracks
serializing typed array flags in a backwards-compatible manner.

Bug: chromium:1284506
Change-Id: Ib32e88c6383e0ad4ad1a9ff63f413a1eb123b1ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3370408
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78507}
2022-01-07 00:54:14 +00:00
Igor Sheludko
52407c5533 [ext-code-space] Avoid Code <-> CodeT conversions in runtime, pt.3
This CL
* migrates FeedbackVector::optimized_code to CodeT,
* migrates OSROptimizedCodeCache to CodeT.

Bug: v8:11880
Change-Id: I2082412fb9fdf90e7ed90f4454ecf55f4f3d53d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330468
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78367}
2021-12-14 13:13:46 +00:00
Igor Sheludko
a0108291e2 [ext-code-space] Avoid Code <-> CodeT conversions in runtime, pt.2
This CL migrates JSFunction's code accessors to CodeT.

Bug: v8:11880
Change-Id: I8cf367eb79cc1d59548dd4f3e18c010f76f101cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330466
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78365}
2021-12-14 12:19:05 +00:00
Marja Hölttä
e9dfaac532 [rab / gsab] Add tests for the recent DataView bugs
In addition, make the code less confusing and more future proof:
- initialize the JSArrayBufferView bit_field to 0 (not only zeroing the
relevant bits)
- serialize it as uint32, since it's an uint32.

Bug: v8:11111
Change-Id: Iffbbb27cc8c821587f992668bfbcf2448a776f15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300132
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78075}
2021-11-24 16:20:29 +00:00
Marja Hölttä
8d0404d80b Reland [rab/gsab] Add RAB / GSAB support to DataViews
Previous version: https://chromium-review.googlesource.com/c/v8/v8/+/3259648

Fix 1: ValueSerializer <3 JSArrayBufferView
Fix 2: set flags correctly when creating DataViews via the API

Bug: v8:11111
Change-Id: I9cbfdaff29f97c7823eaa3d931689b363e1f4cf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297708
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78046}
2021-11-23 16:48:54 +00:00
Samuel Groß
e84ac8bc3b [sandbox] Disallow ArrayBuffers outside the VM Cage
In a follow-up CL, the backing stores will, when the sandbox is enabled,
be referenced from V8 objects through offsets rather than raw pointers.
For that to work, all backing stores must be located inside the virtual
memory cage. This CL prepares for that.

Bug: chromium:1218005
Change-Id: Ibb989626ed7094bd4f02ca15464539f4e2bda90f
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114136
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76486}
2021-08-25 09:52:38 +00:00
Dan Elphick
ec06bb6ce5 Reland "[include] Split out v8.h"
This is a reland of d1b27019d3

Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-24 13:08:55 +00:00
Dan Elphick
44fe02ced6 Revert "[include] Split out v8.h"
This reverts commit d1b27019d3.

Reason for revert: Broke vtune build, tsan build and possibly others

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
2021-08-23 11:54:09 +00:00
Dan Elphick
d1b27019d3 [include] Split out v8.h
This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.

Every include of v8.h from inside v8 has been changed to a more
fine-grained include.

Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.

None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.

v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.

Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing

Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
2021-08-23 09:35:06 +00:00
Shu-yu Guo
ddd6996715 [regexp] Remove --harmony-regexp-match-indices
RegExp match indices have shipped since M90

Bug: v8:9548
Change-Id: I8bf54ce1a50b5079aad71140f75c979a09aae5bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042842
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75848}
2021-07-22 02:28:42 +00:00
Dan Elphick
9010201c99 [base] Create base/strings.h
Moves VSNPrintf, SNPrintf and StrNCpy out of utils/utils.h into
base/strings.h.

Bug: v8:11879
Change-Id: I0e165cb27c42f89c9acd1c6378514b40a90cd18d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972732
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75308}
2021-06-22 16:55:32 +00:00
Clemens Backes
fa3cd68a3f [isolate][cleanup] Remove pointer to WasmEngine
The WasmEngine is shared across the whole process, so there is no need
to store it in every Isolate.
Instead, we can just get it from everywhere on any thread using
{wasm::GetWasmEngine()}, which is a simple read of a global.

R=jkummerow@chromium.org

Bug: v8:11879
Change-Id: I13afb8ca3d116aa14bfaec5a4bbd6d71faa9aa17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969825
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75265}
2021-06-21 09:09:25 +00:00
Dan Elphick
7f5383e8ad [base] Move utils/vector.h to base/vector.h
The adding of base:: was mostly prepared using git grep and sed:
git grep -l <pattern> | grep -v base/vector.h | \
  xargs sed -i 's/\b<pattern>\b/base::<pattern>/
with lots of manual clean-ups due to the resulting
v8::internal::base::Vectors.

#includes were fixed using:
git grep -l "src/utils/vector.h" | \
  axargs sed -i 's!src/utils/vector.h!src/base/vector.h!'

Bug: v8:11879
Change-Id: I3e6d622987fee4478089c40539724c19735bd625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75243}
2021-06-18 13:33:13 +00:00
Igor Sheludko
c2c6bfba5a [ext-code-space] Migrate more code entries to CodeT
Namely,
- StackFrameInfo::code_object
- DependentCode's code entries
- OSROptimizedCodeCache's code entries

Bug: v8:11880
Change-Id: I49bc28f2935dd1561901932a2dfe0bf01bc6836e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969824
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75234}
2021-06-18 08:42:47 +00:00
Clemens Backes
052db704e0 [cleanup] Remove redundant macro list
Just saw this on an unrelated change. This is a left-over from
https://crrev.com/c/2007490.

R=jkummerow@chromium.org

Bug: v8:11384
Change-Id: Iaa6134458e05b58a15ff465b01a86d18bfabd746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2756528
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73381}
2021-03-12 19:24:57 +00:00
Clemens Backes
3f9ff062b0 Reland "[no-wasm] Exclude src/wasm from compilation"
This is a reland of 80f5dfda01. A condition
in pipeline.cc was inverted, which lead to a CSA verifier error.

Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}

TBR=jgruber@chromium.org

Bug: v8:11238
Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 14:29:26 +00:00
Clemens Backes
92bc3d3861 Revert "[no-wasm] Exclude src/wasm from compilation"
This reverts commit 80f5dfda01.

Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview

Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}

Bug: v8:11238
Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73346}
2021-03-11 13:09:09 +00:00
Clemens Backes
80f5dfda01 [no-wasm] Exclude src/wasm from compilation
This is the biggest chunk, including
- all of src/wasm,
- torque file for wasm objects,
- torque file for wasm builtins,
- wasm builtins,
- wasm runtime functions,
- int64 lowering,
- simd scala lowering,
- WasmGraphBuilder (TF graph construction for wasm),
- wasm frame types,
- wasm interrupts,
- the JSWasmCall opcode,
- wasm backing store allocation.

Those components are all recursively entangled, so I found no way to
split this change up further.

Some includes that were recursively included by wasm headers needed to
be added explicitly now.

backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
because it only tests wasm backing stores. This file is excluded from
no-wasm builds then.

R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org

Bug: v8:11238
Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73344}
2021-03-11 12:43:16 +00:00
Clemens Backes
7585aaf3e3 [IWYU] Fix includes of wasm-engine.h
Remove the include from js-array-buffer-inl.h, because the wasm engine
is not used in that file. Add missing includes in other files that
relied on the recursive include.

R=jkummerow@chromium.org

Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I8b7f11ce92858cbc0ccf26925159486ed39573fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739650
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73254}
2021-03-08 11:33:59 +00:00
Clemens Backes
96bfcfb845 [no-wasm] Make --expose-wasm flag readonly
If webassembly is disabled via a gn arg, we will not be able to enable
it via command-line switch. Hence make this flag read-only in that
configuration.

R=ecmziegler@chromium.org

Bug: v8:11238
Change-Id: Ib93a55f74d4f018477f110b8b52aa9b645e86553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710426
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72905}
2021-02-22 12:19:20 +00:00
Shu-yu Guo
81e7e2f437 [regexp] Implement the /d flag for RegExp indices
This CL implements the upcoming spec change:
https://github.com/tc39/proposal-regexp-match-indices/pull/49

A new JSRegExpResultWithIndices subclass is introduced with a separate map and
an extra slot for storing the indices. If /d is passed, exec() constructs a
JSRegExpResultWithIndices and eagerly builds indices.

The existing re-execution logic is removed.

Bug: v8:9548
Change-Id: Ic11853e7521017af5e8bd583c7b82bb672821132
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616873
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72306}
2021-01-26 04:14:10 +00:00
Jakob Gruber
727d22be0c [compiler] Rename type BailoutId to BytecodeOffset
This reflects the actual contents of the type, which is an offset into
the bytecode (or certain marker values). Historically, in the days of
FCG the bailout id used to refer to node ids - this is why certain
tracing output still calls the bailout id 'node id' and 'ast id'.
These spots will be fixed in a follow-up CL.

This change is mechanical:

 git grep -l BailoutId | while read f; do \
  sed -i 's/BailoutId/BytecodeOffset/g' $f; done

With a manual component of updating the DeoptimizationData method
name from 'BytecodeOffset' to 'GetBytecodeOffset'.

Bug: v8:11332
Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72189}
2021-01-20 13:03:41 +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
Seth Brenith
2bbf333379 Require the first three fields of ScopeInfo to be present
ScopeInfo objects generally start with three fields: flags, parameter
count, and local variable count. But a single read-only ScopeInfo
instance has none of those fields. This is the empty ScopeInfo, which is
used for contexts that don't correspond to any scope (the native context
and contexts for builtin functions). Since there is only ever a single
instance of the empty ScopeInfo, the memory savings of omitting these
fields is trivial, and we can simplify logic somewhat by including them.
Rather than checking for length to be zero, this change introduces a new
flag indicating that a ScopeInfo instance is the empty one.

On its own, this change doesn't provide a whole lot of value. However,
it sets us up for two further improvements, which are consistent with
the goals outlined in [1]:

1. We should fully describe ScopeInfo fields in Torque. Getting rid of
the requirement to check for emptiness would substantially simplify the
indexed field expressions.

2. ScopeInfo shouldn't inherit from FixedArray, and shouldn't begin with
a `length` field when the length can be computed from the other fields.
This would save a small amount of heap memory and avoid any possibility
of a mismatch between the two ways of computing the length.

[1] https://docs.google.com/document/d/1tiGK7_lubxPHnInI2vscUwMHfadn8gIEa1apmI8HxR4/edit#heading=h.n63k76b3zfwa

Bug: v8:8952
Change-Id: I018127698a5d91fb2a91684bc3aec2e27ee27c41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2561598
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71500}
2020-11-30 16:23:05 +00:00
Leszek Swirski
f47e59e045 [asserts] Make assert scopes LocalHeap friendly
Because of LocalHeap safepoints, our existing assert scopes don't
necessarily maintain the same guarantees as desired. In particular,
DisallowHeapAllocation no longer guarantees that objects don't move.

This patch transitions DisallowHeapAllocation to
DisallowGarbageCollection, to ensure that code using this scope is
also protected against safepoints.

Change-Id: I0411425884f6849982611205fb17bb072881c722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71319}
2020-11-20 17:39:14 +00:00
Zhi An Ng
b8761260dc [cleanup] Remove DISALLOW_COPY_AND_ASSIGN in test/{common,unittests}
Bug: v8:11074
Change-Id: I7b34b6a647bf9ad317bdb97a344739302f892957
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519184
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70997}
2020-11-06 06:07:54 +00:00
Martin Bidlingmaier
5720d2056c [regexp] Add 'l' flag to force experimental engine
This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
that forces execution in linear time.  These regexps are handled by the
experimental engine.  If the experimental engine cannot handle the
pattern, an exception is thrown on creation of the regexp.

The commit also adds a new global V8 flag and changes an existing one:
* --enable-experimental-engine, which turns on recognition of the RegExp
  'l' flag.  Previously this flag also caused all supported regexps to
  be executed by the experimental engine; this is not the case anymore.
* --default-to-experimental-regexp-engine takes over the previous
  semantics of --enable-experimental-regexp-engine:  We execute all
  supported regexps with the experimental engine.

Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#70892}
2020-10-30 08:33:06 +00:00
Leszek Swirski
1546be9cf8 [runtime] Move string table off-heap
Changes the isolate's string table into an off-heap structure. This
allows the string table to be resized without allocating on the V8 heap,
and potentially triggering a GC. This allows existing strings to be
inserted into the string table without requiring allocation.

This has two important benefits:

  1) It allows the deserializer to insert strings directly into the
     string table, rather than having to defer string insertion until
     deserialization completes.

  2) It simplifies the concurrent string table lookup to allow resizing
     the table inside the write lock, therefore eliminating the race
     where two concurrent lookups could both resize the table.

The off-heap string table has the following properties:

  1) The general hashmap behaviour matches the HashTable, i.e. open
     addressing, power-of-two sized, quadratic probing. This could, of
     course, now be changed.

  2) The empty and deleted sentinels are changed to Smi 0 and 1,
     respectively, to make those comparisons a bit cheaper and not
     require roots access.

  3) When the HashTable is resized, the old elements array is kept
     alive in a linked list of previous arrays, so that concurrent
     lookups don't lose the data they're accessing. This linked list
     is cleared by the GC, as then we know that all threads are in
     a safepoint.

  4) The GC treats the hash table entries as weak roots, and only walks
     them for non-live reference clearing and for evacuation.

  5) Since there is no longer a FixedArray to serialize for the startup
     snapshot, there is now a custom serialization of the string table,
     and the string table root is considered unserializable during weak
     root iteration. As a bonus, the custom serialization is more
     efficient, as it skips non-string entries.

As a drive-by, rename LookupStringExists_NoAllocate to
TryStringToIndexOrLookupExisting, to make it clearer that it returns
a non-string for the case when the string is an array index. As another
drive-by, extract StringSet into a separate header.

Bug: v8:10729
Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69270}
2020-08-06 12:27:18 +00:00
Dan Elphick
6574a7133d [Respect] Rename lists
This changes black/white list to block/allow list.

Bug: v8:10619
Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68464}
2020-06-22 15:15:31 +00:00
Victor Gomes
33081e58f8 [unittests] Convert to the new MOCK_METHOD macro.
Change-Id: I3a624b9cb164dd4a49606f311f71ea0115afe30a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238572
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68296}
2020-06-10 15:50:38 +00:00
Andreas Haas
401190baf0 [wasm] Fix return value of concurrent memory.grow
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.

As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.

R=gdeepti@chromium.org
CC=rreverser@google.com

Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
2020-04-14 21:37:32 +00:00
Dan Elphick
b097a8e5de [api] Create v8::String::NewFromLiteral that returns Local<String>
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.

Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.

This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.

This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.

As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.

Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
2020-03-09 12:02:07 +00:00
Clemens Backes
d968ae0acc [api] Deprecate SetExpectInlineWasm
This flag was used for IndexedDB support. Last uses in chrome were
removed in https://crrev.com/c/2013046, hence the API method can be
deprecated.

Also remove deserializer tests that were disabled by default or just
test that random bytes (from the deserializer's perspective) fail
to decode.

R=adamk@chromium.org

Bug: v8:10146
Change-Id: I8596849c3b51ab1c60272a49ff3fdaa0946452bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013104
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65931}
2020-01-22 20:41:28 +00:00
Clemens Backes
67b6af7ca5 [api] Rename instance check for WasmModuleObject
Both the API wrapper as well as the internal object are named
"WasmModuleObject". This CL renames the object type check from
"IsWebAssemblyCompiledModule" to "IsWasmModuleObject" to be consistent.

R=adamk@chromium.org

Bug: v8:10021
Change-Id: I6d5814421f38bc5f5bd73a492ff4a36f552ff763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013109
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65930}
2020-01-22 19:38:12 +00:00
Clemens Backes
30e4ba6df4 [wasm] Remove serialization of WasmModuleObject
Serialization of WasmModuleObject was our first implementation for
postMessage, and was used for IndexedDB. IndexedDB support is removed
since a long time, and postMessage works by just messaging an identifier
and reusing the underlying NativeModule when receiving this.
Thus the logic to serialize the actual code is unused, and thus should
be removed together with all tests.

R=ahaas@chromium.org

Bug: v8:10146
Change-Id: I599296736dabd486c45ced2b6e5996e490fa40c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013110
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65922}
2020-01-22 16:38:26 +00:00
Clemens Backes
a184598fb4 [wasm] Deprecate unused {DeserializeOrCompile} API
This API was used for IndexedDB support and for transferring modules by
serializing and deserializing (before we were sharing code between
isolates). Last uses were removed in https://crrev.com/c/1847366, thus
this whole API is unused by now.
This CL deprecates the API and refactors tests to use the internal APIs
instead.

R=adamk@chromium.org

Bug: v8:10146
Change-Id: I838039b4be7ea4eebe6769f31f48e51e7bcd4645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006090
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65908}
2020-01-22 08:46:23 +00:00
Dominik Inführ
fb26d0bb18 [objects] Compact and shrink script_list
So far creating scripts always grew the script_list without ever
reusing cleared slots or shrinking. While this is probably not a
problem with script_list in practice, this is still a memory leak.

Fix this leak by using WeakArrayList::Append instead of AddToEnd.
Append adds to the end of the array, but potentially compacts and
shrinks the list as well. Other WeakArrayLists can use this method as
well, as long as they are not using indices into this array.

Bug: v8:10031
Change-Id: If743c4cc3f8d67ab735522f0ded038b2fb43e437
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967385
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65640}
2020-01-08 17:48:32 +00:00
Simon Zünd
73f3d2b1ae Introduce stack locals black list field on the ScopeInfo object
This CL is a prepatory step towards moving the stack locals blacklist
from the DebugEvaluateContext to the respective {ScopeInfo} objects.

The locals blacklist is used during local debug evaluate to
decide whether a context lookup can advance the context chain
upwards, or if lookup needs to stop at the current scope.

This CL also introduces a "Recreate" static helper method, that
allows an existing ScopeInfo to be cloned, but with a locals
blacklist attached. This will be needed since blacklists are only
created on-demand during debugging.

R=leszeks@chromium.org

Bug: chromium:1027475, v8:9938
Change-Id: I673dbc99ce9fdc84cb5cda3f9710ba2b76ab92ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946349
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65380}
2019-12-09 10:25:27 +00:00
Andreas Haas
bfe3d6bce7 [api] Deprecate [Shared]ArrayBuffer::Externalize/GetContents and constructors
The new API with v8::BackingStore should be used instead as explained in
https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k

This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to
not require externalization first.

Bug: v8:9380, v8:9908
Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64625}
2019-10-29 22:01:54 +00:00
Seth Brenith
8c7ae31456 [torque] Generate instance types
Design doc:
https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit

Changes from the design doc:
- Changed to use 'class' declarations rather than 'type' declarations
  for things that need instance types but whose layout is not known to
  Torque. These declarations end with a semicolon rather than having a
  full set of methods and fields surrounded by {}. If the class's name
  should not be treated as a class name in generated output (because
  it's actually a template, or doesn't exist at all), we use the
  standard 'generates' clause to declare the most appropriate C++ class.
- Removed @instanceTypeName.
- @highestInstanceType became @highestInstanceTypeWithinParentClassRange
  to indicate a semantic change: it no longer denotes the highest
  instance type globally, but only within the range of values for its
  immediate parent class. This lets us use it for Oddball, which is
  expected to be the highest primitive type.
- Added new abstract classes JSCustomElementsObject and JSSpecialObject
  to help with some range checks.
- Added @lowestInstanceTypeWithinParentClassRange so we can move the new
  classes JSCustomElementsObject and JSSpecialObject to the beginning of
  the JSObject range. This seems like the least-brittle way to establish
  ranges that also include JSProxy (and these ranges are verified with
  static assertions in instance-type.h).
- Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
- Renamed @instanceTypeFlags to @reserveBitsInInstanceType.

This change introduces the new annotations and adds the ability for
Torque to assign instance types that satisfy those annotations. Torque
now emits two new macros:
- TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
  InstanceType enumeration
- TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
  parts of INSTANCE_TYPE_LIST

The design document mentions a couple of other macro lists that could
easily be replaced, but I'd like to defer those to a subsequent checkin
because this one is already pretty large.

Bug: v8:7793
Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64258}
2019-10-11 22:37:22 +00:00
Ulan Degenbaev
77ff0a5566 Refactor construction of [Shared]ArrayBuffers.
The backing store is now propagated to the constructors directly,
instead of being attached after the construction. This ensures that
the backing store is allocated before the array buffer so that we can
trigger GCs on backing store allocation (if allocation fails).

The only exception is builtin where we have to allocate the array buffer
before the backing store to comply with the spec.

Bug: v8:9380
Tbr: verwaest@chromium.org
Change-Id: Ib37db65853f3673dd769368cc3e8b6538ad07ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1853444
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64240}
2019-10-11 13:04:45 +00:00
Clemens Backes
6f8381958c [wasm] Remove obsolete --no-wasm-shared-code flag
The flag is enabled since M-70, and we do not use the previous
behaviour anywhere. Hence, remove the flag and clean up some API code.
In particular, the concept of {TransferrableModule} is not needed any
more, we can just use {CompiledWasmModule}.

R=mstarzinger@chromium.org, adamk@chromium.org

Bug: v8:9810
Change-Id: I9b3aa4972277a9262b58da70b141e90d1de31f35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847366
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64209}
2019-10-10 09:01:45 +00:00
Mythri A
fcff24370b Reland "[compiler] Cache OSR optimized code"
This is a reland of cfb100282e
with a fix for failures in lite mode.

Original change's description:
> [compiler] Cache OSR optimized code
>
> With lazy feedback allocation, for functions that get OSRed we may
> not have feedback for the initial part of the functions since feedback
> vectors might be allocated after the function started executing. Hence
> we would not be able to optimize the function on the next call. This
> means we may have to OSR twice before we actually optimize function.
> This cl introduces OSR cache, so we could reuse the optimized code. One
> side effect of this cl is that the OSRed code won't be function context
> specialized anymore.
>
> Bug: chromium:987523
> Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64014}

Bug: chromium:987523
Change-Id: I9c782242b07b24d15247533ab4ee044334b429ff
TBR: rmcilroy@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826898
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64023}
2019-09-27 13:25:47 +00:00
Michael Achenbach
f8a08223d6 Revert "[compiler] Cache OSR optimized code"
This reverts commit cfb100282e.

Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/6483

Original change's description:
> [compiler] Cache OSR optimized code
> 
> With lazy feedback allocation, for functions that get OSRed we may
> not have feedback for the initial part of the functions since feedback
> vectors might be allocated after the function started executing. Hence
> we would not be able to optimize the function on the next call. This
> means we may have to OSR twice before we actually optimize function.
> This cl introduces OSR cache, so we could reuse the optimized code. One
> side effect of this cl is that the OSRed code won't be function context
> specialized anymore.
> 
> Bug: chromium:987523
> Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64014}

TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org

Change-Id: Ib3692e7570bed5d3e88ca8a0247b185d70497a04
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:987523
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826668
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64015}
2019-09-27 12:09:13 +00:00
Mythri A
cfb100282e [compiler] Cache OSR optimized code
With lazy feedback allocation, for functions that get OSRed we may
not have feedback for the initial part of the functions since feedback
vectors might be allocated after the function started executing. Hence
we would not be able to optimize the function on the next call. This
means we may have to OSR twice before we actually optimize function.
This cl introduces OSR cache, so we could reuse the optimized code. One
side effect of this cl is that the OSRed code won't be function context
specialized anymore.

Bug: chromium:987523
Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64014}
2019-09-27 09:30:52 +00:00
Ulan Degenbaev
55c48820f8 [api] Add [Shared]ArrayBuffer::GetBackingStore()
This adds an additional V8 API to get the backing store of an array
buffer. Unlike the existing API, the backing store comes wrapped
in a std::shared_ptr, making lifetime management with the embedder
explicit. This obviates the need for the old GetContents() and
Externalize() APIs, which will be deprecated in a future CL.

Contributed by titzer@chromium.org


Bug: v8:9380
Change-Id: I8a87f5dc141dab684693fe536b636e33f6e45173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807354
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63883}
2019-09-19 10:03:02 +00:00
Ulan Degenbaev
b6b7de0d60 Reland x6 [arraybuffer] Rearchitect backing store ownership
This reverts commit 9da3483136

Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>

> Cr-Commit-Position: refs/heads/master@{#63041}

TBR=yangguo@chromium.org

Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63617}
2019-09-09 13:07:42 +00:00