- 14 Jul, 2021 1 commit
-
-
Emanuel Ziegler authored
This is a reland of dcdaf42f. It adds CPU time metrics to the WasmModuleDecoded (except for streaming), WasmModuleCompiled and WasmModuleTieredUp events. This can later be used to provide this information as UKMs or UMAs. Bug: v8:11611 Change-Id: I813fc8de36d1445c6a887abf496ec10e1a803815 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953296Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#75715}
-
- 13 Jul, 2021 4 commits
-
-
Clemens Backes authored
This is a reland of dacce720 Original change's description: > [wasm] Fix fallback from PKU to mprotect > > The {WasmCodeManager::SetThreadWritable} method would return true if > called in a nested scope, even if PKU is not available. The caller > cannot tell then whether permission switching happened or not. > > This CL refactors the code to do an explicit check for PKU support, and > removes the boolean return value from {SetThreadWritable}. > > R=jkummerow@chromium.org > > Bug: v8:11959, v8:11974 > Change-Id: I2d45f1fa240305c6f92f63cdf190131d637bfe95 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021383 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75699} Bug: v8:11959, v8:11974 Change-Id: I7086aa3f1cd12615e6f12bbd061084ecd325eb11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021180Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75707}
-
Clemens Backes authored
This reverts commit dacce720. Reason for revert: Needs a fix. Original change's description: > [wasm] Fix fallback from PKU to mprotect > > The {WasmCodeManager::SetThreadWritable} method would return true if > called in a nested scope, even if PKU is not available. The caller > cannot tell then whether permission switching happened or not. > > This CL refactors the code to do an explicit check for PKU support, and > removes the boolean return value from {SetThreadWritable}. > > R=jkummerow@chromium.org > > Bug: v8:11959, v8:11974 > Change-Id: I2d45f1fa240305c6f92f63cdf190131d637bfe95 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021383 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75699} Bug: v8:11959, v8:11974 Change-Id: I199cf6dd6e12a209649fcf86f922e2500b50bbde No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021179 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@{#75700}
-
Clemens Backes authored
The {WasmCodeManager::SetThreadWritable} method would return true if called in a nested scope, even if PKU is not available. The caller cannot tell then whether permission switching happened or not. This CL refactors the code to do an explicit check for PKU support, and removes the boolean return value from {SetThreadWritable}. R=jkummerow@chromium.org Bug: v8:11959, v8:11974 Change-Id: I2d45f1fa240305c6f92f63cdf190131d637bfe95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021383 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75699}
-
Clemens Backes authored
Since PKU-based switching always switches the permissions for all wasm code memory in the process, the method should not be on the {NativeModule} or {WasmCodeAllocator}, but instead on the process-wide {WasmCodeManager}. R=jkummerow@chromium.org Bug: v8:11974 Change-Id: I75a82e51401b2572977c134077e1669cf5077049 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021382 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75694}
-
- 05 Jul, 2021 1 commit
-
-
Clemens Backes authored
This is a three-state field now: kTrapHandler, kExplicitBoundsChecks, kNoBoundsChecks. It is set once based on the flags (--wasm-bounds-checks and --wasm-enforce-bounds-checks) and depending on whether the signal handler for wasm trap handling was installed. All compilation then only uses the field value, and does not need to check any flags any more. R=ahaas@chromium.org Bug: v8:11926 Change-Id: I2c0eb5ecb742ee65d1c10e4dceff7204119dab7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996191 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75558}
-
- 24 Jun, 2021 2 commits
-
-
Jakob Kummerow authored
Instead, make the array-allocating builtin initialize the object. This speeds up later stages of Turbofan graph processing, in particular live range computation. Bug: v8:7748 Change-Id: Iba0d682922b444b1d6151eeaee8d939821ebc980 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983457 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#75367}
-
Clemens Backes authored
There is only one global wasm engine, so we do not need to store the pointer in the NativeModule. We just use {GetWasmEngine()} instead, which reads the global pointer. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I66dedd571755774d96621b8d20ff23bdfef8134f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983208Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75366}
-
- 22 Jun, 2021 1 commit
-
-
Clemens Backes authored
This is a reland of 0f90a2aa. The issue was inverted destructor order between WasmCodeManager and WasmEngine. WasmEngine has to be destructed first, because it contains a barrier to ensure that background compile threads finished before global state is being destructed. Original change's description: > [wasm] Provide a global WasmCodeManager > > The WasmCodeManager was part of the WasmEngine so far, but there is only > exactly one WasmEngine. Hence we can pull it out, and also remove the > pointer in the WasmCodeAllocator. > > The argument passed from the single constructor call is now inlined in > the constructor itself. > > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just > "CommitPageSize()". > > R=jkummerow@chromium.org > > Bug: v8:11879 > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75270} Bug: v8:11879 Change-Id: I0eaa2395f5c1e30f3f7303c5f3df70c227b74d3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975859 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75289}
-
- 21 Jun, 2021 4 commits
-
-
Maya Lekova authored
This reverts commit 0f90a2aa. Reason for revert: Breaks MSAN, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/38941/overview Original change's description: > [wasm] Provide a global WasmCodeManager > > The WasmCodeManager was part of the WasmEngine so far, but there is only > exactly one WasmEngine. Hence we can pull it out, and also remove the > pointer in the WasmCodeAllocator. > > The argument passed from the single constructor call is now inlined in > the constructor itself. > > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just > "CommitPageSize()". > > R=jkummerow@chromium.org > > Bug: v8:11879 > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75270} Bug: v8:11879 Change-Id: I110eec313762d73073f530aec7cf0be82c4db344 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972921 Auto-Submit: Maya Lekova <mslekova@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@{#75274}
-
Daniel Lehmann authored
Merges `NativeModuleModificationScope` (with an implementation using Intel PKU, if available, and mprotect otherwise) and `CodeSpaceWriteScope` (for Apple Silicon, where switching to RWX with mprotect is disallowed anyway, so MAP_JIT and thread-local switching must be used). Because `CodeSpaceWriteScope` sounded better (and is shorter), we kept its name (which unfortunately makes the diff a bit harder to read). R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11714 Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Change-Id: Ib2a7d18e72797a725ed34b904c70769166d811dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972911Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Daniel Lehmann <dlehmann@google.com> Cr-Commit-Position: refs/heads/master@{#75272}
-
Clemens Backes authored
The WasmCodeManager was part of the WasmEngine so far, but there is only exactly one WasmEngine. Hence we can pull it out, and also remove the pointer in the WasmCodeAllocator. The argument passed from the single constructor call is now inlined in the constructor itself. Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just "CommitPageSize()". R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75270}
-
Daniel Lehmann authored
In an effort to merge `CODE_SPACE_WRITE_SCOPE` and `NativeModuleModificationScope`, this CL moves the interface and implementation of the latter into code-space-access.{h,cc}, where the former already lives. No other changes to the code itself. R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11714 Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Change-Id: I1aabce26f2033430523a7a3a0a4864e7267bee21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972803Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Daniel Lehmann <dlehmann@google.com> Cr-Commit-Position: refs/heads/master@{#75267}
-
- 18 Jun, 2021 2 commits
-
-
Clemens Backes authored
The {WasmCodeManager::CanRegisterUnwindInfoForNonABICompliantCodeRange} method does not access any information on the {WasmCodeManager} object, hence make it static. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I9a06ec556825bc7709970b65f22156952fa7f191 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972726 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75246}
-
Dan Elphick authored
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/+/2968412Reviewed-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}
-
- 16 Jun, 2021 1 commit
-
-
Jakob Kummerow authored
When we pass function arguments on the stack, untagged parameters "come first", i.e. are put to lower addresses / can be popped off first. So when a function instructs the stack walker to visit its parameters (belonging to its caller's frame), it must skip past any untagged parameters at the top of the caller's frame. Change-Id: I5a42e4850b0808237ae937c90b0cec930df8571b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964394 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#75180}
-
- 15 Jun, 2021 1 commit
-
-
Santiago Aboy Solanes authored
In the same vein we did tagged stores, we can do tagged loads. As a drive-by, move GetTSANRelaxedStoreStub to CodeFactory. Bug: v8:7790, v8:11600 Change-Id: Ic1ef3245623756538eab64c3358047e3797195c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953162 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75145}
-
- 14 Jun, 2021 2 commits
-
-
Clemens Backes authored
M1 hardware uses the CodeSpaceWriteScope (which uses MAP_JIT under the hood), hence all other memory protection mechanisms should be disabled there. Trying to protect code space allocated with MAP_JIT would fail otherwise, resulting in a CHECK failure. R=jkummerow@chromium.org CC=dlehmann@chromium.org Bug: chromium:1218782 Change-Id: I626990575c2180168c2e421a93b9f0b035382f03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2959613 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75123}
-
Santiago Aboy Solanes authored
This is the last CL of the code generated stores. Bug: v8:7790, v8:11600 Change-Id: If8bbabb422027f938c7acc0bdc12a233dfed580e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2950760 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75121}
-
- 07 Jun, 2021 2 commits
-
-
Camillo Bruni authored
- Add new Builtin enum - Move Builtins::Name:kXXX to Builtin::kXXX - Update existing code Follow CLs will unify the mix of using int builtin-ids and Builtins::Name to only use the new Builtin enum and changing it to an enum class. Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74995}
-
Santiago Aboy Solanes authored
Introduce EmitTSANStoreOOLIfNeeded methods which make it easier on the eyes in code-generator.cc. Also pass along the size, which lays the groundwork for the other instructions e.g. kX64Movq since we don't require the store to be a Tagged one. This creates new builtins (since we now have a version with 32 bits and another one for 64 bits stores). We can extract the common code in builtins-internal-gen.cc to de-duplicate the common code. Bug: v8:7790, v8:11600 Change-Id: I81d80b852ec96b94d170a20f6d61621743b74b32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933664Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74971}
-
- 02 Jun, 2021 2 commits
-
-
Jakob Kummerow authored
This instruction is a non-standard V8-only experiment for now, hidden behind the --experimental-wasm-gc-experiments flag. The motivation is to provide a way to set up non-canonicalized RTT hierarchies, to enable expressing the type system of Java-like languages in terms of WasmGC constructs. Bug: v8:7748 Change-Id: Idf1c18e9944c983f40f1e01b2032ee5fdc2fd81b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930478Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74920}
-
Daniel Lehmann authored
Similar to https://crrev.com/c/2912786, this fixes a high number of page permission switches (incuring mprotect syscall and lock contention overhead) by pulling a {NativeModuleModificationScope} outside of a loop (and across a function boundary). R=clemensb@chromium.org CC=jkummerow@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:11663, chromium:932033 Change-Id: I2ec47f3eeeb2ab9624d2eaea9b4e776738871c97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928504Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Daniel Lehmann <dlehmann@google.com> Cr-Commit-Position: refs/heads/master@{#74906}
-
- 27 May, 2021 1 commit
-
-
Manos Koukoutos authored
Changes: - Add --experimental-wasm-gc-experiments flag. - Add array.copy opcode. Implement it in decoding and code generation behind the new flag. - Add WasmCodeBuilder::BoundsCheckArrayCopy. Move BoundsCheckArray to the private section. - Add WasmArrayCopy and WasmArrayCopyWithChecks builtin. - Add WasmArrayCopy runtime function. - Add WasmArray::ElementSlot. - Always print two hex digits in CHECK_PROTOTYPE_OPCODE. - In test-gc, print the thrown-error message if the function should not throw. - In test-gc, add GetResultObject with one argument. Bug: v8:7748 Change-Id: I58f4d37e254154596cdef5e78482b55260dd3782 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912729 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74806}
-
- 26 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Inline the SaveFPMode flag directly into the TSANRelaxedStore stubs: - Saves one register for input arguments - Avoid branches in the TSANRelaxedStore stubs Bug: v8:7790, v8:11600 Change-Id: Ib1083f8c1a7e856028ff606ba8c2a93efb10db69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917037Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74781}
-
- 25 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
This is a reland of 50cbeca9 Relanding as-is, only rebase-related changes. Reason for reland: was speculatively reverted. Original change's description: > [codegen] Use builtin calls for TSANRelaxedStore > > Instead of calling the C function directly from codegen, we call a > builtin that calls the C function. This is done to encapsulate the > push/pop registers in the code in the builtin. > > Bug: v8:7790, v8:11600 > Change-Id: I4c77a80803d4eb44526b716901afe0e8ccbe077d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892663 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74599} Bug: v8:7790, v8:11600 Change-Id: Ide78ca82f38ee84bb7d24f5da2b4e8a8bd26621a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914877Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74751}
-
- 20 May, 2021 1 commit
-
-
Milad Fa authored
gcc may throw the following compilation error if UNREACHABLE is used within a constexpr function: ``` error: call to non-'constexpr' function 'void V8_Fatal(const char*, ...)' ``` Bug: v8:11420 Change-Id: I7f8237d00ba1a5d9bd778d45eb833b89cbe8eb24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906032 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74688}
-
- 19 May, 2021 1 commit
-
-
Camillo Bruni authored
Inline the RememberedSetAction and SaveFPMode flags directly into the RecordWrite stubs: - Save two register for input arguments - Avoid branches in the RecordWrite stubs We end up with 2 stubs for the EphemeronKeyBarrier and 4 stubs for RecordWrite. Due to more inlined calls we have roughly 1KiB more builtins code for RecordWrite currently. We will address this in the future by splitting out common code into a separate stub. There is no additional code size overhead for EphemeronKeyBarrier. This saves 4 to 8 bytes on x64 per RecordWrite call and 2.5% sparkplug code size reduction on d3.min.js. Bug: v8:11420 Change-Id: Ib7170265dd6dd4b3aaf8275083f096e76fae8251 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902731Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74661}
-
- 18 May, 2021 1 commit
-
-
Sathya Gunasekaran authored
This reverts commit 50cbeca9. Reason for revert: speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/3824/overview Original change's description: > [codegen] Use builtin calls for TSANRelaxedStore > > Instead of calling the C function directly from codegen, we call a > builtin that calls the C function. This is done to encapsulate the > push/pop registers in the code in the builtin. > > Bug: v8:7790, v8:11600 > Change-Id: I4c77a80803d4eb44526b716901afe0e8ccbe077d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892663 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74599} Bug: v8:7790 Bug: v8:11600 Change-Id: I3a4c57a29346fe6c84ec11404d8ff64cfac51a70 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902926 Auto-Submit: Sathya Gunasekaran <gsathya@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@{#74622}
-
- 17 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Instead of calling the C function directly from codegen, we call a builtin that calls the C function. This is done to encapsulate the push/pop registers in the code in the builtin. Bug: v8:7790, v8:11600 Change-Id: I4c77a80803d4eb44526b716901afe0e8ccbe077d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892663Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74599}
-
- 11 May, 2021 1 commit
-
-
Daniel Lehmann authored
This is the second CL in a line of two to implement PKU-based WebAssembly code space write protection. The first CL added two low-level PKU functions; this CL uses them to grant/withdraw writable permissions, local to each thread that wants to modify the code space. In particular, when {--wasm-memory-protection-keys} is enabled, we first associate a memory protection key with all code pages, which by default does not allow any write access. Then, before each location that needs to modify the code space, we open {NativeModuleModificationScope}s (which are already present for mprotect-based write protection). When the PKU flag is given, this then first tries to set permissions of a memory protection key (which is fast), and otherwise when {--wasm-write-protect-code-memory} is enabled, falls back to mprotect-based write protection (which is much more expensive and also not thread-local, but for the whole process). R=clemensb@chromium.org Bug: v8:11714 Change-Id: I3527906a8d9f776ed44c8d5db52539e78e1c52fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882800 Commit-Queue: Daniel Lehmann <dlehmann@google.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74501}
-
- 07 May, 2021 1 commit
-
-
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}
-
- 04 May, 2021 1 commit
-
-
Andreas Haas authored
WebAssembly.Function and functions of the C-API do not have a function index. Their index is kAnonymousFuncIndex = -1. Therefore it is necessary to change the return type of WasmCode::index() from uint to int. The changes in WasmFrame::Print produces output like the following: [9]: CWasmEntryFrame [pc: 0x9d200084091] [10]: Anonymous wasm wrapper [pc: 0x101c5975c972] [11]: WASM [wasm://wasm/f4bee83a], function #1 ('fibonacci_wasm'), pc=0x101c5975c5dc (+0x7c), pos=123 (+32) R=jkummerow@chromium.org Bug: v8:11713 Change-Id: I1012e92713d64d24ed2a92729dd3c2e4a013b9c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871455Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74355}
-
- 03 May, 2021 2 commits
-
-
Michael Achenbach authored
This reverts commit a4c37558. Reason for revert: Speculative revert. Seems to break all gpu builders, e.g.: https://ci.chromium.org/p/v8/builders/ci/Linux%20V8%20FYI%20Release%20(NVIDIA)/14577 See shards for detailed output, e.g.: https://chromium-swarm.appspot.com/task?id=534a8fbeaca4df10 Check failed: valid_arguments. V8.WasmMemoryProtectionKeysSupport Original change's description: > [wasm] Add PKU alloc/free and support counter > > 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), this associates a key with each page once, and then changes > 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) trying to allocate a protection key once per {WasmEngine} in x64 > Linux systems, and > (2) adding a counter for recording the sucess/failure of that, to assess > the support for PKUs on the target machine. > > The low-level PKU allocating functions should be moved into base/platform > long-term, but are inside wasm/ for this CL. > > R=clemensb@chromium.org > CC=jkummerow@chromium.org > > Bug: v8:11714 > Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932 > Commit-Queue: Daniel Lehmann <dlehmann@google.com> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74319} Bug: v8:11714 Change-Id: I70349d413ac9092e2f033d138887678bfecaae17 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2868607 Auto-Submit: Michael Achenbach <machenbach@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@{#74339}
-
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), this associates a key with each page once, and then changes 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) trying to allocate a protection key once per {WasmEngine} in x64 Linux systems, and (2) adding a counter for recording the sucess/failure of that, to assess the support for PKUs on the target machine. The low-level PKU allocating functions should be moved into base/platform long-term, but are inside wasm/ for this CL. R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11714 Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932 Commit-Queue: Daniel Lehmann <dlehmann@google.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74319}
-
- 24 Apr, 2021 1 commit
-
-
Daniel Lehmann authored
This is the second CL in a line of two (see crrev.com/c/2835237) to bring write-protection to the WebAssembly code space. The previous CL changed the page permissions from W^X (only either writable or executable can be active, but never both) to write-protection (due to concurrent execution in the main thread). However, write-protection still did not work, because in several places the code space is modified without properly switching it to writable beforehand. This CL fixes --wasm-write-protect-code-memory such that it can now be enabled again (with potentially high overhead due to frequent page protection switches). For that, it adds the missing switching to writable by adding {NativeModuleModificationScope} objects (similar to the already existing {CodeSpaceWriteScope} objects for Apple M1 hardware). This CL also fixes a race condition between checking for the current writable permission and actually setting the permission, by protecting the counter of currently active writers with the same lock as the {WasmCodeAllocator} itself. (Before multi-threaded compilation, this was not necessary.) Finally, this CL also changes the {Mutex} protecting the {WasmCodeAllocator} to a {RecursiveMutex} because it can be requested multiple times in the call hierarchy of the same thread, which would cause a deadlock otherwise. Since {TryLock()} of a {RecursiveMutex} never fails, this also removes the (now failing) DCHECKs. R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11663 Change-Id: I4db27ad0a9348021b0b663dbe88b3432a4d8d6b5 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835238 Commit-Queue: Daniel Lehmann <dlehmann@google.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74163}
-
- 19 Apr, 2021 2 commits
-
-
Daniel Lehmann authored
The --wasm-write-protect-code-memory flag previously enforced W^X, that is the WebAssembly code space was either writable or executable, but never both at the same time. With compilation in background threads concurrent to execution in the main thread, this simple scheme is no longer viable because the same memory page can indeed be written to and executed at the same time. Hence, this flag is currently broken and disabled and the code space is always writable AND executable. As a first step towards more security, we at least want to write-protect the code space (when not required writable by compilation threads) but at the same time keep it always executable (because of concurrent execution in the main thread). That is, we no longer switch between RX and RW (W^X), but rather between RX and RWX (write-protection only). This CL starts to change from W^X (which was broken) to write-protection only when enabling --wasm-write-protect-code-memory. This is the first of two CLs, where the followup CL will fix the feature, and this CL merely prepares and cleans up the code. In particular, this CL changes the permissions from RW to RWX (due to concurrent execution) and renames `WasmCodeAllocator::SetExecutable()` to `WasmCodeAllocator::SetWritable()` (and similarly named callers) to be consistent with that change. Since the code space is now always executable, this CL also removes now unneeded calls to `SetExecutable(true)` in tests. R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11663 Change-Id: I2065eed6770215892b81daefbddf74a349e783cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835237Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Daniel Lehmann <dlehmann@google.com> Cr-Commit-Position: refs/heads/master@{#74041}
-
Clemens Backes authored
This changes the interaction between {NativeModule} and {WasmCodeAllocator}. The {WasmCodeAllocator} is a field of {NativeModule}, and only called directly by the {NativeModule}. So far, there were two mutexes involved, the {allocation_mutex_} in {NativeModule}, and {mutex_} in {WasmCodeAllocator}. This caused problems with lock order inversion. This CL thus merges the two mutex, by always locking the mutex in {NativeModule} when calling a non-atomic method in {WasmCodeAllocator}. This serializes slightly more code, but none of this should be performance-critical. This removes the awkward {OptionalLock} class and adds the "Locked" suffix to a few methods to document that those can only be called while holding the allocation mutex. R=jkummerow@chromium.org CC=dlehmann@google.com Bug: v8:11663 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_gc_stress_dbg_ng Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng Change-Id: I8895d61fef23a57b218e068532375bac941a5a77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831477 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74026}
-
- 15 Apr, 2021 1 commit
-
-
Thibaud Michaud authored
We currently allow OSR (On-Stack Replacement) of arbitrarily deep return addresses. This is in direct violation of Intel CET's shadow stack, which we plan to enable eventually. This change works around this by postponing OSR until after we return to the old code. The main changes are: - Reserve a slot in Liftoff frames to store the OSR target, - Skip the return address modification, and instead store the new code pointer in the dedicated slot, - Upon returning to the old code, check the slot and do an indirect jump to the new code if needed. CET also prevents indirect jumps to arbitrary locations, so the last point is also a CET violation. Valid indirect jump targets must be marked with the ENDBRANCH instruction, which I will do in a follow-up CL. Bug: v8:11654 Change-Id: I6925005211aa95d60803b9409e3c07c7c226b25c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826127 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73977}
-
- 09 Apr, 2021 1 commit
-
-
Michael Achenbach authored
This reverts commit dcdaf42f. Reason for revert: This has problems on mac-arm64: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/3591 Original change's description: > [wasm] Add CPU time metrics > > This adds CPU time metrics to the WasmModuleDecoded (except for streaming), > WasmModuleCompiled and WasmModuleTieredUp events. This can later be used > to provide this information as UKMs or UMAs. > > Bug: v8:11611 > Change-Id: I36818f5efbdcae2d3ed6f27c16db21f9d8440d98 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2796952 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73882} Bug: v8:11611 Change-Id: I1c82c3e4f19b3a486538fd62665669f6c5b98438 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2818380 Auto-Submit: Michael Achenbach <machenbach@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@{#73884}
-