- 07 May, 2021 16 commits
-
-
Georg Neis authored
It was using MakeRef but it's not guaranteed that we can create a Ref for the prototype if we haven't seen it during serialization. Use TryMakeRef instead. Tbr: jgruber@chromium.org Bug: chromium:1206670, v8:7790 Change-Id: Ifc00cb1dbf7747c766011f5915bb15fe093b920c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878749Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74442}
-
arthursonzogni authored
This reland patch: https://chromium-review.googlesource.com/c/v8/v8/+/2867473 (See patchset 1) The problem was blink injecting interceptor into the window object. It observes "observation" and "mutations" on this object. When it happens to the initial empty document, the IPC DidAccessInitialDocument() is sent and modify the state of the browser process. Causing two tests to fail. The diff (See patchset 1..2) includes: 1. Use JSObject::HasRealNamedProperty instead of JsObject::HasProperty. This skips the interceptor and do not walk the prototype chain. 2. Invert JSObject::HasRealNamedProperty() with IsSharedArrayBufferConstructorEnabled(), just in case. This avoid observing the object when not needed. Original patch description: --- This change makes it possible to enable SharedArrayBuffer per Context, controlling whether it should be enabled or not with a callback. The previous implementation of the reverse origin trial for SharedArrayBuffer was broken, since the feature could only be enabled globally per process, and only if the feature flag is set early enough in the v8 initialization. This does not play well with how origin trials work. The implementation is similar to the callbacks that already exist for the origin trials for WebAssembly simd and exceptions. SharedArrayBuffer is still controlled by the flag harmony_sharedarraybuffer. If that flag is disabled, then SharedArrayBuffer is disabled unconditionally. On top of that, this CL introduces a new flag for enabling SharedArrayBuffer per context. If that flag is set, a callback is used to determine whether SharedArrayBuffer should be enabled. Note that this only controls whether the SharedArrayBuffer constructor should be exposed on the global object or not. It is always possible to construct a SharedArrayBuffer using new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor; There are few things which I do not like of this approach, but I did not have better ideas: 1. The complex logic of dobule flag + callback. However, this seemed the best way to me to not break embedders which rely on that flag being enabled by default. 2. The fact that what actually matters is just whether the callback returns `true` once. It would be good to check that the callback gives a consistent return value, or to provide a better API that cannot be missunderstood. Bug: chromium:923807,chromium:1071424,chromium:1138860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Antonio Sartori <antoniosartori@chromium.org> Cr-Commit-Position: refs/heads/master@{#74378} --- Bug: chromium:923807,chromium:1071424,chromium:1138860,chromium:1206187 Change-Id: Ibc6b4f8c0e0827178b7f0cbe4b942444bbbe6216 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880215Reviewed-by:
Lutz Vahl <vahl@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74441}
-
Jakob Kummerow authored
Hopefully making it easier to determine the problem when a dynamically-sized object type allows too small sizes. Change-Id: Iac33c501da6349e02f570fe8c9092758cd9d59a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874654 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74440}
-
Milad Fa authored
Using xxbrq we can reverse the order of indices in a single instruction. xxbrq is also implemented in the simulator in this CL. Change-Id: I4744cefeec0a4e07b41fcb0d35de08ad42e55883 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878573Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74439}
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: Ifa1f8d4c1b1003e9d33f1c9b42e6647388c56d01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878746Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74438}
-
Sigurd Schneider authored
Our current logic for the console API's monitor implementation relies on JavaScript's arguments array. In arrow functions, this results in an error, resulting missing print statements from monitor. This CL at least re-enables the print statements, but does not print the arguments in the case of arrow functions. Change-Id: Ibf6c2a0fb5e0cc911c257520a59a875992fe3777 Bug: chromium:1206137 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880216Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#74437}
-
Jakob Kummerow authored
Structs with zero fields weren't handled correctly, because the GC has a requirement that each object occupies at least two pointers. On the high end, Wasm structs accidentally had a limit of 255 pointers including object header. This CL bumps that to the intended limit of 999 fields (which is arbitrary and could be raised if needed). Bug: v8:7748 Change-Id: I13a3f45b3ddb28023c76775da32be0d07ec2ffd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874653 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#74436}
-
Daniel Lehmann authored
To enforce W^X for the WebAssembly code space, we want to explore using Intel memory protection keys for userspace, also known as MPK, PKEYs, or PKU. Instead of flipping page protection flags with mprotect (which incurs a high syscall overhead; and which switches flags for the whole process), with PKU we associate a key with each page once and then change the permissions of that key with a fast thread-local register write. That is, this gives both finger-grained permissions (per-thread) and more performance. This CL is starts experimenting with PKUs by (1) adding a flag to turn on prototype PKU support; and if set to true (2) allocates a protection key once per {WasmCodeManager} in x64 Linux systems. This is a partial reland of https://crrev.com/c/2850932, which was reverted due to an added histogram failing Chromium integration. Since the histogram (to record PKU support) is independent of the functionality in this CL, we split it out into its own CL (to come). R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11714 Change-Id: I67c8679495c55fa51da8243582963649abde660b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878738 Commit-Queue: Daniel Lehmann <dlehmann@google.com> Reviewed-by:Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74435}
-
Jochen Eisinger authored
Bug: chromium:728583 Change-Id: Ie7a46ff884ae9474d342c50e5c6cdcf5c0c0e46a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874397Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#74434}
-
Victor Gomes authored
This is a reland of b271648e Unfortunately the test can still throw a fatal error, since there are other possible paths for OOM. Original change's description: > [runtime] Add length check in ConvertElementsWithCapacity > > This also propagates the exception through all the users of > ConvertElementsWithCapacity. > > Bug: chromium:1201626 > Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74412} Bug: chromium:1201626 Change-Id: I164ca1aca21ad6f45ccf8893fb07a47cd5ed079a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2877833Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74433}
-
Clemens Backes authored
'override' implies 'virtual', thus 'virtual' should be skipped. R=mlippautz@chromium.org Bug: v8:11717 Change-Id: If5e9c2aeec85fcf0832f9712b6e09752c4d2c2d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878737Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74432}
-
Michael Lippautz authored
The application may itself change ASAN poisoning which conflicts with the memset() right before poisoning memory. This is relevant for destructors but also when invoking Resize() on an object that uses ASAN container annotations. Annotations are hard to adjust for the embedder as it is not clear upfront whether the call will succeed. Bug: chromium:1056170 Change-Id: I7f719e4130ba6149494a45f220a341658970bc6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878733Reviewed-by:
-
Dominik Inführ authored
The DCHECK seems to fail with MSVC on x86 builds. This CL disables this DCHECK when map packing isn't enabled until we have a proper fix. Bug: v8:11748, v8:11624 Change-Id: Iec98d161c5cd2b6a910c29287b54c8e3de017e83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878735Reviewed-by:
-
Dominik Inführ authored
This CL changes the accounting of array buffers, such that Detach deducts the backing store immediately. Previously this was corrected in the next GC cycle. Not updating backing_store_bytes_ immediately could cause an overflow in WasmMemoryObject::Grow. Grow first detaches the backing store from the old JSArrayBuffer and then attaches it to a new one. This results in the backing store being accounted twice temporarily, this could cause overflows on 32-bit systems. Bug: chromium:1204455 Change-Id: I7cf2ca9a12bb5caf7bcffa25a34567774cf155b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871458 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Frank Tang authored
This API is the new public one added in ICU 69.1 in https://github.com/unicode-org/icu/pull/1610 Bug: v8:11512 Change-Id: I424e15e6a60edee7c98e6ce55974986f0bb6ab1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876368 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74428}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a5d4757..c844180 Rolling v8/buildtools/linux64: git_revision:6771ce569fb4803dad7a427aa2e2c23e960b917e..git_revision:dfd036f3be5422c7b61cf16369bde28b3a8cccc8 Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/5844fc6..d6f21e0 Rolling v8/third_party/aemu-linux-x64: QpXtlWg0Hrksvqhm2JkK5cg7xWznHgNj3aHSgOF-cCkC..IFKk3HKRVi_NvWa_9abMZahaAGY7hGQ0MzuloLf6TkgC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5185110..c92267a Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5009fd6..e77e3c8 Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/d0c227c..a2e8a8a TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ib75fb34c07ee7d1c1fe84a2f77dc6575b35053d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878903Reviewed-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@{#74427}
-
- 06 May, 2021 24 commits
-
-
Anton Bikineev authored
gcc complains about the 'extern "C"' going after attributes. Bug: v8:11710 Change-Id: If253c73bdfb2473267511d556950da37b80f790b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2877797Reviewed-by:
-
Zhi An Ng authored
This reverts commit 6c65e858. Reason for revert: V8 Linux64 fyi bots are red https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20fyi/21963/overview Original change's description: > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64 > > Bug: v8:11460 > Change-Id: I9ab419b5e90fbe677e1d63b41699d90552839e98 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873226 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74422} Bug: v8:11460 Change-Id: Ia97838cdce5073cbdb8eaa3aa819aa92c2a081dd No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878854 Auto-Submit: Zhi An Ng <zhin@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@{#74425}
-
Ng Zhi An authored
Tbr: mslekova@chromium.org Bug: v8:11745 Change-Id: Ib29745f9926810a4b1a18c8b779e62e1d9f69f2e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2877863Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#74424}
-
Mike Stanton authored
HeapNumberRef can be serialized in the background, so long as we record a dependency to check at the end of compilation to ensure that the number (interpreted as bits) has not changed. Bug: v8:7790 Change-Id: I5c1c27466192580ff33bd55c8fa44dac957f2171 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2872827 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Shu-yu Guo authored
Bug: v8:11460 Change-Id: I9ab419b5e90fbe677e1d63b41699d90552839e98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873226 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74422}
-
Milad Fa authored
Change-Id: I3cda4c4ac03a56191e4c034aef34879c23da993d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876449Reviewed-by:
-
Milad Fa authored
Port 05265d88 Original Commit Message: This removes all wasm-related flags in no-wasm builds. We could have made them read-only, but fully removing them actually forces us to consider the no-wasm case at every use site, which often hints at further cleanups. R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I2340276a05a9a67756d128501e1e88a77c56effe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876451Reviewed-by:
-
Dominik Inführ authored
The test reads slack properties after the end of the object. With FLAG_stress_concurrent_allocation a background thread allocates a lot of objects and might cause concurrent sweeping which causes a TSAN race. Since this only happens with this test, disable the test in this configuration. Bug: v8:11698 Change-Id: If922a4a233006d3719294ae2f3a05820117e9250 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856536Reviewed-by:
-
Omer Katz authored
Destroyed large pages can be reallocated before the OS get a chance to reclaim and clear them. In such cases we will get non-zero memory in a newly allocated page. Normal pages are not affected since they are kept in page pools instead of being freed. Fix by explicitly clearing the payload when destroying a large page. Bug: chromium:1056170, chromium:1206274 Change-Id: I6436302f50b8f0b4ef41288425bf464b0eb52d5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874404 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Daniel Clark authored
It turns out that KeyAccumulator::GetKeys will fail if the object it is operating on is a Proxy with an ownKeys() or getOwnPropertyDescriptor() trap that throws. Handle this case in Isolate::GetImportAssertionsFromArgument by bailing out early. Bug: v8:11730 Change-Id: I363bf2d218f6ba7eeb2001cd644f5529901fdb3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2875541Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74417}
-
Anton Bikineev authored
The change broke msvc build. This CL fixes it. Original change description: > This reverts commit 97b4ed74. > > Microsoft x86_64 ABI considers XMM6-XMM15 as non-volatile > (callee-saved), which means that the compiler can store pointers in them. > We need to make sure they are pushed onto the stack inside the stack > scanning trampolines. > Bug: v8:11710 > Change-Id: Ida804fe49d3d3b6f179ec276903a42ec8d3d86be > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865745 > Commit-Queue: Anton Bikineev <bikineev@chromium.org> > Auto-Submit: Anton Bikineev <bikineev@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74376} Bug: v8:11710 Change-Id: I5357ceffe4dce5c570a15d8be86d6db11926e88c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876846Reviewed-by:
-
Samuel Groß authored
The heap sandbox mode was broken after the introduction of WasmExportedFunctionData objects due to missing external pointer handling. This CL implements that. Bug: v8:10391 Change-Id: Icc6a2944b68f475c40b6431ab26400c35083b7bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862771Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#74415}
-
Clemens Backes authored
This reverts commit b271648e. Reason for revert: New test fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/42282/overview Original change's description: > [runtime] Add length check in ConvertElementsWithCapacity > > This also propagates the exception through all the users of > ConvertElementsWithCapacity. > > Bug: chromium:1201626 > Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74412} Bug: chromium:1201626 Change-Id: I764256e9d0dcc69ea3a2f3c77afaca73a910bb66 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876861 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@{#74414}
-
Fanchen Kong authored
When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer: receiver.apply(this, args) -> this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target is not a heapconstant. With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%. function reduceArray(func, arr, r) { for (var i = 0, len = arr.length; i < len; i++) { r = func.apply(null, r, arr[i]); } return r; } var a = 0; for (var i = 0; i < 10000000; i++) { a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1); } console.log(a); This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls. Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by: -
Victor Gomes authored
This also propagates the exception through all the users of ConvertElementsWithCapacity. Bug: chromium:1201626 Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Milad Fa authored
Port dc7906c9 R=victorgomes@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: Ic6643492969efcf4113a25a886792038b291cacf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876987Reviewed-by:
-
Benedikt Meurer authored
Within the inspector we should be consistent about passing the script ID always as integer, and only convert to String16 when actually needed. That (a) saves memory (and some runtime overhead) when stashing away call frames, for example in case of async stack traces, and (b) reduces confusion which representation to chose. Bug: chromium:1162229 Change-Id: I9591931da0a307779372f36aba6e155ec22bbe3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876856 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#74410}
-
QiuJi authored
Also remove the out of date comment after constant pool enabled. Change-Id: I80ded0242406097dfdb35e1356ed8fa7e43b2f00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839546Reviewed-by:
Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Cr-Commit-Position: refs/heads/master@{#74409}
-
Clemens Backes authored
The test takes several minutes on slower bots, so speed it up a bit without removing the ability to hit the data race. R=ulan@chromium.org Bug: chromium:1205290, v8:11741 Change-Id: I57e411bfa2ff2a22bef1a916b74f7684b2f0be17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876855Reviewed-by:
-
Clemens Backes authored
After dropping support for older GCC versions, we can now assume full c++14 constexpr support, and can hence resolve a TODO to make a LiftoffCompiler method constexpr. This is also a proof-of-concept to verify that this indeed works on all bots now. R=ahaas@chromium.org Bug: v8:9686, v8:11384 Change-Id: I9b7da91152b0af98778312d653aebbf4236fed0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876850Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74407}
-
Victor Gomes authored
Change-Id: I824a671c54c92975a94f9dc56e993d532f022ce6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874401Reviewed-by:
-
Wenyu Zhao authored
Bug: v8:11641 Change-Id: I675b6968219a315a4b6f4bf1899d81931b5b4e0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2875316 Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au> Reviewed-by:
-
Nico Hartmann authored
This reverts commit bc1eb7b4. Reason for revert: https://ci.chromium.org/ui/p/chromium/builders/try/android-pie-arm64-rel/369203/overview Original change's description: > [api] Add API callback setter for the SAB origin trial > > This change makes it possible to enable SharedArrayBuffer per Context, > controlling whether it should be enabled or not with a callback. The > previous implementation of the reverse origin trial for > SharedArrayBuffer was broken, since the feature could only be enabled > globally per process, and only if the feature flag is set early enough > in the v8 initialization. This does not play well with how origin > trials work. > > The implementation is similar to the callbacks that already exist for > the origin trials for WebAssembly simd and exceptions. > > SharedArrayBuffer is still controlled by the flag > harmony_sharedarraybuffer. If that flag is disabled, then > SharedArrayBuffer is disabled unconditionally. On top of that, this CL > introduces a new flag for enabling SharedArrayBuffer per context. If > that flag is set, a callback is used to determine whether > SharedArrayBuffer should be enabled. > > > Note that this only controls whether the SharedArrayBuffer constructor > should be exposed on the global object or not. It is always possible > to construct a SharedArrayBuffer using > > new WebAssembly.Memory({ > shared:true, initial:0, maximum:0 }).buffer.constructor; > > > There are few things which I do not like of this approach, but I did > not have better ideas: > > 1. The complex logic of dobule flag + callback. However, this seemed > the best way to me to not break embedders which rely on that flag > being enabled by default. > > 2. The fact that what actually matters is just whether the callback > returns `true` once. It would be good to check that the callback gives > a consistent return value, or to provide a better API that cannot be > missunderstood. > > > Bug: chromium:923807,chromium:1071424,chromium:1138860 > Change-Id: Ibe3776fad4d3bff5dda9066967e4b20328014266 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Antonio Sartori <antoniosartori@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74378} Bug: chromium:923807 Bug: chromium:1071424 Bug: chromium:1138860 Change-Id: Iec678dee130db891c2096e47bc072a5d77ae9476 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874403 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Clemens Backes authored
For copying the SharedArrayBuffer content, we cannot use a simple {memcpy} because that produces data races with thread concurrently modifying the content. Instead, use a custom {Relaxed_Memcpy} that uses proper relaxed atomics. The implementation is slightly optimized to do word-sized loads and stores where possible. If we still get performance regressions, we can optimize it further in follow-up CLs. R=ulan@chromium.org CC=mlippautz@chromium.org Bug: v8:11704, chromium:1205290 Change-Id: Ie34afc5c22ec5496c0fe822d55d4788031f06c54 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874652 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
