- 19 Aug, 2020 16 commits
-
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: I1e06f7c87ea05ccb8c73571e9148ff0cb9f574a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362951Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69483}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I44849f45d1049b8a3c794dd0558b734c1e7061fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362919 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69482}
-
Santiago Aboy Solanes authored
Drive-by: Remove a parameter that had to be SKIP_WRITE_BARRIER. Bug: v8:9708, v8:6949 Change-Id: Ib5d0521f255a92749440a5001dab8b59eb078bf9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362950Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69481}
-
Omer Katz authored
This CL adds a basic implementation of incremental marking for standalone GC. Followup CLs include: * Use bytes instead of time as deadline * Port incremental marking schedule from blink * Mark on allocation * Guarantees for progres/termination for standalone GC * etc... Calling StartIncrementalGarbageCollection triggers StartMarking which schedules incremental marking as non-nestable tasks. For unified heap, marking will continue running until it runs out of work but it won't finalize independently. For standalone, when incremental runs out of work it will schedule a new task in which it will finalize marking and trigger the rest of the GC. Users of standalone can also force finalization before incremental marking as finished using FinalizeIncrementalGarbageCollectionIfRunning. Calling CollectGarbage would also finalize an on-going incremental GC if one exists. Otherwise it will trigger an atomic GC. See the following doc for explanation of the various methods: https://docs.google.com/document/d/1ZhJY2fOoD8sH53ZxMh2927Zl8sXqA7azJgcQTWx-YKs/edit?usp=sharing Bug: chromium:1056170 Change-Id: I75ead414eb9da9f8b7f71c4638b9830fce7708ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298009 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69480}
-
Maya Lekova authored
Bug: v8:10813 Change-Id: Ib7b3949147706552a6d569ad5fcd22f2f63d7977 No-Try: True Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364496 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69479}
-
Salome Thirot authored
When CFI is enabled this adds a check against this list whenever a new return address must be set in a deoptimized frame, as a mitigation for ROP attacks. The list is known at linking time so that its content and the pointer to it can be stored in a read-only memory section. The check is performed in the signing function, which is no longer generic, as well as when setting the current pc of the frame. Since the pc is now only signed when setting the caller's pc, there is no need for ReplaceContext anymore. Bug: v8:10026 Change-Id: I5e85a62b94722051716fdeba476db383c702a318 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com> Cr-Commit-Position: refs/heads/master@{#69478}
-
Jakob Kummerow authored
When running with --verify-heap, ObjectVerify() is invoked for every live object anyway, so there is no need for individual FooVerify() implementations to recursively request verification of their sub-objects. If they do, (a) it is duplicated work of O(n²) complexity, and (b) it can cause fuzzer-generated tests to crash because they run out of stack space when they trigger heap verification with very little stack space left. Fixed: chromium:1106426 Change-Id: Ib9bd444806b148fffc23d635f931dfe73fe7e4ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358746 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69477}
-
Anton Bikineev authored
The issue popped up while implementing conservative stack scanning in V8. Bug: v8:10614 Change-Id: I7edc6ca1f248f45b10be0fa45e28a98fd2b03840 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362651 Auto-Submit: Anton Bikineev <bikineev@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69476}
-
Maya Lekova authored
This reverts commit 7964ac86. Reason for revert: Introduces a data race - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32870 Original change's description: > [compiler] Replace HeapNumberData with direct reads > > Bug: v8:7790 > Change-Id: I3fbbbd36900146111f83596fd6615a2e4a4f5d33 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362952 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69474} TBR=neis@chromium.org,solanes@chromium.org,nicohartmann@chromium.org Change-Id: Idd17677b2083acf452195a88cb5c363034b43c5f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364493Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#69475}
-
Georg Neis authored
Bug: v8:7790 Change-Id: I3fbbbd36900146111f83596fd6615a2e4a4f5d33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362952 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69474}
-
Georg Neis authored
As part of this, introduce a new ObjectData kind for objects that we want to read directly from the background thread rather than serialize. ScopeInfoRef is the first user of that. For details, see: https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing Bug: v8:7790 Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69473}
-
Emanuel Ziegler authored
Add an event for recording metrics related to instantiating Wasm modules. R=clemensb@chromium.org Bug: chromium:1092417 Change-Id: I5c87aba7d2cdb012951249b336684580595844cd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351675 Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69472}
-
Santiago Aboy Solanes authored
We can create a new macro to skip the xxxData classes and read directly from the heap. Bug: v8:7790 Change-Id: I8de9ba0aee78c74d4c3113eb6bc4870a314de552 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362687 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69471}
-
Emanuel Ziegler authored
Add an event for recording metrics related to compiling Wasm modules. This provides different events for both baseline compilation and tier-up. R=clemensb@chromium.org Bug: chromium:1092417 Change-Id: Ib5ea7f5ba9e91e2c34473e666eea1c6dc6a97037 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351674 Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69470}
-
Jakob Gruber authored
... to avoid the repeated pattern of calculating it. Bug: v8:8888 Change-Id: I4af5264aae6cfb8b6232b5aaf9ceb2cb568c29d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362692 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69469}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/13765d6..78b2991 Rolling v8/third_party/aemu-linux-x64: p5IjOVYEoaWHNJ28H6OKk3LlpDPCUruvOahozwiZAIgC..cG1zzefbD24rFmPDujqP0rrEG0uXUhH8axBOrD619hoC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/03f5451..abfdfbb Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5664586..5cff4e3 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7c75562..299e8a2 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I8e126fab0c47d9cd9b9112fd93929d91b0f53f00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363898Reviewed-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@{#69468}
-
- 18 Aug, 2020 24 commits
-
-
Andreas Haas authored
The V8 wasm fuzzer can create regression tests for failing fuzzer cases. These regression tests use the wasm-module-builder.js. With the addition of simd to the wasm-compile-fuzzer, the fuzzer can now create test cases that use simd instructions, but the wasm-module-builder.js did not know yet about the new instructions. This CL adds some instructions to wasm-module-builder.js. R=zhin@chromium.org Bug: chromium:1116019 Change-Id: I198e4f11c2225a65d6b438f95e351fc14ee66218 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362694 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69467}
-
Shu-yu Guo authored
This is a normative PR that reached consensus at the June 2019 TC39: https://github.com/tc39/test262/pull/2299 Bug: v8:9646 Change-Id: Idbeea703fe264da43825729e7b37a08a1bb10001 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360907 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#69466}
-
Milad Farazmand authored
Port 2547e1ce Original Commit Message: Since the compilation progress was never initialized on deserialization, tier down was always skipped on such modules. By initializing to the expected state after deserialization (i.e. all code as TurboFan code), we make sure that later recompilation works as expected. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Iab66ca0d1bfb36cfee56ccd85720d4c5552eb9c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363270Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69465}
-
Clemens Backes authored
Instead of returning a boolean value on {WasmCodeManager::Commit}, and always failing on {false}, just remove the return value and fail within {WasmCodeManager::Commit} directly. This allows us to generate better error messages if running OOM. R=thibaudm@chromium.org Bug: chromium:1107649, chromium:1117033 Change-Id: Ic8089e4385ddf92c164b9a0c770c210e1caddcbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362962Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69464}
-
Dirk Pranke authored
Prior versions of GN had a bug (gn:22) where visibility rules for configs weren't being enforced properly. This CL tweaks the visibility settings of some configs to conform to the latest version. Change-Id: Ic5d827a1f2774278d3894f67fe52bfca836c0409 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360909 Commit-Queue: Dirk Pranke <dpranke@google.com> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#69463}
-
Z Nguyen-Huu authored
There exists such optimization for additions but not for multiplication. This adds optimizations that apply the reductions (x * Int32Constant(a)) * Int32Constant(b)) => x * Int32Constant(a * b) (x * Int64Constant(a)) * Int64Constant(b)) => x * Int64Constant(a * b) to the TurboFan graph. Bug: v8:10305 Change-Id: I28f72c2b7d8ff0f758a0a08b69fb3763557a6241 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360327 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69462}
-
Milad Farazmand authored
Port 360c9294 Original Commit Message: In Liftoff, we were missing kS128 cases to load to/from stack. For the x64 and ARM64 instruction selector, the calculation of reverse_slot is incorrect for 128-bit values: - reverse_slot += 2 (size of 128-bit values, 2 pointers) - this copies from slot -2 into register - but the value starts at slot -1, it occupies slots -1 and -2 - we end up copying slot -2 (most significant half) of the register, and also slot -3, which is where rsi was store (Wasm instance addr) - the test ends up with a different result every time The calculation of reverse_slot is changed to follow how ia32 and ARM does it, which is to start with - reverse_slot = 0 - in the code-generator, add 1 to the slot - then after emitting Peek operation, reverse_slot += 2 The fixes for x64 and ARM64 are in both instruction-selector and code-generator. ia32 and ARM didn't support writing kSimd128 values yet, it was only a missing check in code-generator, so add that in. For ARM, the codegen is more involved, vld1 does not support addressing with an offset, so we have to do the addition into a scratch register. Also adding a test for returning multiple v128. V128 is not exposed to JavaScript, so we use a Wasm function call, and then an involved chain of extract lanes, returning 6 i32 which we verify the values of. It extracts the first and last lane of the i32x4 value in order to catch bugs where we write or read to a wrong stack slot (off by 1). The simd-scalar-lowering for kCall was only handling single s128 return, we adopt the way i64-lowering handles kCall, so that is can now handle any kinds of calls with s128 in the descriptor. R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I1ad9595d7820f04687c9d79941ad04c6eb207897 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363118Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69461}
-
Shu-yu Guo authored
This is a normative PR that reached consensus at the June 2019 TC39: https://github.com/tc39/test262/pull/2299 Bug: v8:9646 Change-Id: I8cb927b9e9231dfb71ebf47171205a096350e38b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360905Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#69460}
-
Thibaud Michaud authored
R=ahaas@chromium.org Bug: chromium:1097717 Change-Id: I6c5a0a32191c9a06fd894c8fe7d9367e9403de8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362956Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69459}
-
Clemens Backes authored
Since the compilation progress was never initialized on deserialization, tier down was always skipped on such modules. By initializing to the expected state after deserialization (i.e. all code as TurboFan code), we make sure that later recompilation works as expected. Drive-by: Fix an unnecessary copy of a {shared_ptr} in deserialization. R=thibaudm@chromium.org Bug: chromium:1110258 Change-Id: Ia12af888e4b11aabfb8cd4e1201e9fa3cd2ceb47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323355 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69458}
-
Seth Brenith authored
In some objects, the length field for an indexed field might itself be conditionally included depending on some previous field's value. The module-related stuff at the end of ScopeInfo is a good example. Torque can represent that case, with a minor change allowing indexed field access from within the length expression for another indexed field. Bug: v8:7793 Change-Id: I9ff5c9cea2b9423f28004beba05a9a24b22c8e3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360328Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69457}
-
Milad Farazmand authored
Port 4765c70f Original Commit Message: On arm, the root register points into the middle of the roots array to allow to use the full int12_t offset range. Therefore some offsets into the root array are negative. This CL changes the liftoff assembler for arm to allow loads from negative offsets. On arm64, offsets can also be negative when pointer compression is disabled. Additionally this CL changes the signature of LiftoffAssembler::LoadTaggedPointer from uint32_t to int32_t to allow the LiftoffCompiler to provide negative indices. This CL does not come with a separate test yet. However, this changes is needed for https://crrev.com/c/2352784. Where there will also be a test. R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ie286b0169a5f7a1de90e0ec7002bfac83383ea6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363127Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69456}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I76db7b605cf3d8ecb994d2eb98ae9566eadb7331 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289775Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69455}
-
evih authored
The wasm instance is not needed after calling the wasm function. Bug: v8:10701 Change-Id: I9b53ecba74873746ee9c163011bca0167969c6c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362691Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Eva Herencsárová <evih@google.com> Cr-Commit-Position: refs/heads/master@{#69454}
-
Andreas Haas authored
On arm, the root register points into the middle of the roots array to allow to use the full int12_t offset range. Therefore some offsets into the root array are negative. This CL changes the liftoff assembler for arm to allow loads from negative offsets. On arm64, offsets can also be negative when pointer compression is disabled. Additionally this CL changes the signature of LiftoffAssembler::LoadTaggedPointer from uint32_t to int32_t to allow the LiftoffCompiler to provide negative indices. This CL does not come with a separate test yet. However, this changes is needed for https://crrev.com/c/2352784. Where there will also be a test. R=thibaudm@chromium.org Bug: v8:7581 Change-Id: I0a97a62ff8e934d45a4494adfbc74a3e1149c8c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2359429Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69453}
-
Santiago Aboy Solanes authored
This is a reland of 0fe7a6cf Original change's description: > [csa][cleanup] Remove ParameterMode/TNodify IntPtrOrSmiConstant > > Bug: v8:9708, v8:6949 > Change-Id: I0a17eab689d8297218af92658bf5e63d34c94dfc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2356387 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69435} Bug: v8:9708 Bug: v8:6949 Change-Id: Ic91d1249cf3178165f2c378122e5700a0f36feb5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361465 Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69452}
-
Maya Lekova authored
This reverts commit 1dd7f3a9. Reason for revert: Breaks TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32846? Original change's description: > [heap] Add concurrent marking write barrier > > A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to > the marking barrier is set to a thread_local variable for a quick access. > > WriteBarrier::MarkingSlow fetches the thread_local variable and invokes > the write barrier if it is set. Otherwise, it invokes the main thread > heap()->marking_barrier(). > > Each marking barrier has its own local marking worklist that is > published during scavenge (for updating pointers) and at finalization > of incremental marking. > > Typed-slot recording does not work yet because it is not thread-safe. > It will be fixed in a subsequent CL. > > Bug: v8:10315 > Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69448} TBR=ulan@chromium.org,dinfuehr@chromium.org Change-Id: I9719d565aaa313cd23f5e759dcef1246f475eb46 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362689Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#69451}
-
Ross McIlroy authored
MSVC on x86 has issues with ALIGNAS(8) on InstructionOperand, but does align the object to 8 bytes anyway. As a work-around, avoid ALIGNAS for InstructionOperand on MSVC x86. BUG=v8:10796 Change-Id: Iabb465489d97f9518a4429e8d78c06296539ed97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358680Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69450}
-
Clemens Backes authored
{NativeModuleDeserializer::ReadCode} always returned {true}. Thus remove this return value and the code handling a {false} return. R=thibaudm@chromium.org Bug: chromium:1110258 Change-Id: I2cf76936f6eea213e6318ea35bdb58b2ded801c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352782Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69449}
-
Ulan Degenbaev authored
A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to the marking barrier is set to a thread_local variable for a quick access. WriteBarrier::MarkingSlow fetches the thread_local variable and invokes the write barrier if it is set. Otherwise, it invokes the main thread heap()->marking_barrier(). Each marking barrier has its own local marking worklist that is published during scavenge (for updating pointers) and at finalization of incremental marking. Typed-slot recording does not work yet because it is not thread-safe. It will be fixed in a subsequent CL. Bug: v8:10315 Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69448}
-
evih authored
GC support works for the current 0 and 1 param version of the wrapper. Bug: v8:10701 Change-Id: I9e3822b1481223c44050d23ddee7293936f1e6d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351673Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Eva Herencsárová <evih@google.com> Cr-Commit-Position: refs/heads/master@{#69447}
-
Clemens Backes authored
This is a reland of 899cb348. The new fuzzer regression test is skipped in jitless. Original change's description: > [wasm][fuzzer] Fix exception detection > > Exceptions were detected by checking for a pending exception on the > isolate, but {CallWasmFunctionForTesting} was clearing any pending > exception before returning. > This CL fixes that by explicitly passing back a boolean which is set if > an exception occurred during execution. > > R=ahaas@chromium.org > > Bug: chromium:1115280 > Change-Id: Ife71ceef0751d18e0870335b9520c2bf77e351cc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352787 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69404} Bug: chromium:1115280 Change-Id: I9bb7300d423c53214e51e61233b0a6b09a21fd97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361464Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69446}
-
Almothana Athamneh authored
Change-Id: I711d2b8e67ad80731b805353520988f796d6a95d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358678Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#69445}
-
Ulan Degenbaev authored
Instead of forcing GC right away, the function now post a task and performance GC from the task with an empty stack to avoid false positive pointers in conservative stack scanning. Bug: chromium:1098187 Change-Id: I88864845a1e395056c5d5f6e867ad774b87dbb6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307217 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69444}
-