- 04 Aug, 2021 23 commits
-
-
Victor Gomes authored
Bug: v8:11872 Change-Id: I6d133ee33b48fa1f02442564b6a30d56986758eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071401Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76092}
-
Clemens Backes authored
For some reason, the "ret" instruction goes missing on Mac release builds, probably because the compiler decides to split the inline assembly block and move the "v8_probe_memory_continuation" block somewhere else. This CL fixes that by adding another explicit "ret" at the end of "ProbeMemory". Also, we remove the "v8_probe_memory_address" symbol (which is identical to just "ProbeMemory"), to prevent the compiler from splitting "ProbeMemory" and "v8_probe_memory_address". R=ahaas@chromium.org Bug: v8:11955 Change-Id: I2e63b2db94206e329be214ab7b553ab502d6ecc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071202Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76091}
-
Patrick Thier authored
Maximum frame size (in bytes) is used to check for stack overflows in the prologue. The maximum number of call arguments is pre-calculated and included in this check. However the count was added to the frame size wihout converting the count to bytes, resulting in inaccurate stack overflow checks. Bug: chromium:1235182 Change-Id: I21bca4e183fccfd055f2f1d5a40b71651c14b911 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071399Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#76090}
-
Jakob Gruber authored
Convert more raw Handle<Map> uses to MapRef. Bug: v8:7790 Change-Id: Id638b70607aa5a73404ee37dfda5e038018be525 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067337 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76089}
-
Omer Katz authored
In crrev.com/c/3056970 I merged reporting allocated bytes from CppHeap to v8 with reporting from cppgc to CppHeap. The reporting handler assumed in_no_gc_scope() is false. Unfortunately this breaks. On heap termination, cppgc will report to CppHeap but CppHeap will have entered a no gc scope when it detached from the isolate. We could adjust the DCHECK, but I think it's simpler to revert to the previous unmerged state and simply port the bug fix from crrev.com/c/3056970 (i.e. lines 484-486 in cpp-heap.cc in this CL). Bug: chromium:1056170 Change-Id: I5aa953c31388f7b3bb3326ff10d5a33961be2aa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067227Reviewed-by: Anton Bikineev <bikineev@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#76088}
-
Jakob Kummerow authored
The merge values of a block have to be initialized to their static types, even if the actual values on the stack have subtypes of the loop's static type. Drive-by cleanup: drop some unneeded manual {TestModuleBuilder} instantiations from existing tests. The test fixture provides one anyway. Bug: chromium:1234453 Change-Id: I39c7eae4b6a6d5124f29be92da5ee92ff7e20e57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068948Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#76087}
-
Georg Neis authored
Bug: chromium:1234974 Change-Id: I4227853b9e6f232b7e17037cdac01c4f80320464 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069281 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76086}
-
Leszek Swirski authored
Bug: chromium:1232620 Change-Id: Ie19fe8839966a1abb3d0a01fee1fb4b105fb6bf1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070702 Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76085}
-
Benedikt Meurer authored
This is a reland of ce8cef36 Original change's description: > [inspector] Consistently format all native accessors as own properties. > > Previously the V8 inspector would only turn embedder accessors on the > prototype chain into data properties, but would not do the same for > ECMAScript builtins, which is kind of inconsistent and weird behavior. > > This leaves in the hack that the inspector reports native accessor > properties as (own) data properties, but now at least the very least > does so consistently. In the absence of a better solution, we'll go > with this for now. > > Bug: chromium:1076820, chromium:1199247 > Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f > Before: https://imgur.com/kPuSldj.png > After: https://imgur.com/eFau45m.png > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#76059} Bug: chromium:1076820, chromium:1199247 Change-Id: I11987194b0d0b8b250eda4f8ce0ae5fc743eb27c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070701 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#76084}
-
Camillo Bruni authored
Bug: v8:10284 Change-Id: If199cbe09964f66aa7346eedefb8ad57fe945c9d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069152 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76083}
-
Clemens Backes authored
We can avoid the scratch register by directly using the operand in the "sub" instruction. R=victorgomes@chromium.org Bug: v8:12017 Change-Id: Ib1768a92b0ef98bf7dbed522f467eff395d08e8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069138Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76082}
-
Sathya Gunasekaran authored
git secrets keeps complaining that the previous string was a possible credential. This patch changes it to be less like a credential and removes the annoying warning. Change-Id: I5074a4e3c11ab0d689b1a88e8d3eec0794dad899 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070699Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#76081}
-
Jakob Gruber authored
The field is immutable after initialization and thus should be set non-atomically on the main thread, and read non-atomically on the background thread. But TSAN support for generated code turns all field accesses into relaxed atomic accesses, leading to this race detection. Silence it by making the read relaxed as well. Bug: chromium:1236302,v8:7790 Change-Id: I47979b2dbf61a65a9e92453324fe2b255fafd30d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070700 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76080}
-
Peter Varga authored
Bug: none Change-Id: Ia8beb0ec2c5eec8689ecdf49132b795fad0e97ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069156Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76079}
-
Jakob Gruber authored
These should be reenabled when the underlying issue is fixed. Bug: v8:7790,v8:12031 Change-Id: Id950cceaa10209b17c2857d61183a2394638d6fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068951 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76078}
-
Camillo Bruni authored
- Add separate script-details.h file - Follow-up CL will add support for precise caching with custom host options Bug: v8:10284 Change-Id: I37be2079434ba7029c160ca811c7ce00a147f539 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069151 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76077}
-
Jakob Gruber authored
.. when not concurrent-inlining. These were accidentally removed for all configurations, but should have been removed only for --concurrent-inlining. Removed in crrev.com/c/3059683. Bug: v8:7790,chromium:1236298 Change-Id: I39695a515b87139f0b1bf3e247e3038146a7d754 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069154 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76076}
-
Mythri A authored
Add support to flush only baseline code. FLAG_flush_baseline_code controls if baseline code is flushed or not and FLAG_flush_bytecode controls if bytecode is flushed or not. With this CL it is possible to control if we want to flush only bytecode / only baseline code / both. This also lets us have different heuristics for bytecode and baseline code flushing. Bug: v8:11947 Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#76075}
-
Jakob Gruber authored
Invalid ref construction (should assume a memory fence), and invalid unconditional use of an optional ref. Bug: v8:7790,chromium:1236303,chromium:1236307 Change-Id: Id0a12222d3d29a0728290ad5269da0946647a5ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070698 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76074}
-
Camillo Bruni authored
Follow-up CLs will use the ScriptDetails object for code cache lookups instead of only the ScriptOriginOptions. Bug: v8:10284 Change-Id: Idc83e6e79cfca283369a9b5ceab8bc53dae5f2dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069149 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76073}
-
Liu Yu authored
Port b4e62f2d Bug: v8:11420 Change-Id: I6b834611ec246244d109eb9065dca1d0c4a9c0c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070380 Auto-Submit: Liu yu <liuyu@loongson.cn> Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#76072}
-
Sathya Gunasekaran authored
This reverts commit ce8cef36. Reason for revert: broke blink tests: https://ci.chromium.org/ui/p/chromium/builders/try/mac-rel/751822/overview Original change's description: > [inspector] Consistently format all native accessors as own properties. > > Previously the V8 inspector would only turn embedder accessors on the > prototype chain into data properties, but would not do the same for > ECMAScript builtins, which is kind of inconsistent and weird behavior. > > This leaves in the hack that the inspector reports native accessor > properties as (own) data properties, but now at least the very least > does so consistently. In the absence of a better solution, we'll go > with this for now. > > Bug: chromium:1076820, chromium:1199247 > Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f > Before: https://imgur.com/kPuSldj.png > After: https://imgur.com/eFau45m.png > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#76059} Bug: chromium:1076820, chromium:1199247 Change-Id: Ib090e0a1dad26f5c9684d906b775555b6a07cca0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069012Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#76071}
-
Liu Yu authored
Add registers to WriteBarrierDescriptor::registers, because the second and third registers should not be v0; Modify the scratch registers in the baseline to prevent conflicts with WriteBarrierDescriptor::registers; Fix an error in AdjustBaseAndOffset(). Change-Id: Ibd16b280147d03aff03d05db1a5eb2d567d40aa9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069176Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Auto-Submit: Liu yu <liuyu@loongson.cn> Cr-Commit-Position: refs/heads/master@{#76070}
-
- 03 Aug, 2021 17 commits
-
-
Omer Katz authored
Windows can allocate the stack at low addresses. A low-address on-stack slot (e.g. backing store reference for Blink's on-heap collections) with a null value would make TryGetCagedHeap falsely think that the slot resides in a caged heap that starts at a null address. We will still crash for low-address on-stack slots with non-null on-stack value, since these cases are not considered valid and should not happen. The null value check is added only to Windows. It is not an issue on other OSes where the stack always resides at high addresses and we prefer to keep the write barrier as cheap as possible. Bug: chromium:1230794, chromium:1056170 Change-Id: I07e2d178cd95edba57015d6bc6eb127a443b0589 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069146 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#76069}
-
Lu Yahan authored
Change-Id: I82464ad3ae81843b8e3ac940c079218a55aad67e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041145 Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#76068}
-
Seth Brenith authored
While reading through the jump threading implementation, I noticed something strange: ApplyForwarding iterates through the block list in reverse post-order, not in assembly order. Thus, the value prev_fallthru might not refer to the previous block in assembly order. Obviously it works fine this way or we would have noticed by now, but I think that this step would be a little easier to read and reason about if the iteration used assembly order instead. I've added a test case to demonstrate the difference when using assembly order: in a diamond where the right side starts with an empty deferred block, the current implementation would fail to replace that block with a nop. I doubt this case would have any real-world impact. Change-Id: I28abe2043434debb54896871d15c540ad52c6368 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039261 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76067}
-
Milad Fa authored
I/F 32x4 and 64x2 ReplaceLane opcodes are optimized on P10. Change-Id: I28ddc2b4e66ca39414e9c3ed2efd0eea268f1a07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067803Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#76066}
-
Frank Tang authored
https://chromium.googlesource.com/external/github.com/tc39/test262/+log/afe217b31..ab353c6 Bug: v8:7834, v8:3038, v8:3019, v8:11934, v8:12043, v8:12044, v8:11989 Change-Id: I3fd38aa0c2374f96506c21999f8ea04c9ece4f49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068506Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#76065}
-
Bruce Dawson authored
Windows.h causes massive namespace pollution with its defining of many macros, it adds to build times, it disables warnings, and it makes it easier to write non-portable code. This change removes windows.h from V8's win32-headers.h. It does this by replicating the small number of typedefs that are needed and by defining three "proxy" types that are the same size and layout. The V8ToWindowsType functions are used to reinterpret_cast between the types. Prior to this change there were over 760 v8-related source files that include windows.h. After this change there are 16. Bug: chromium:796644 Change-Id: I89efeed47028faae72de2da4f1dae345d8d7746c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042215 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76064}
-
Milad Fa authored
Port f7de8c80 Original Commit Message: For large frames we are executing a special stack check that checks the remaining stack space before allocating the new frame. Different platforms used different limits for the frame size so far. Liftoff already uses 4KB everywhere, hence use the same limit also for TurboFan. simplification. R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: Ie47572277769170878c3ed5598fe61edd8524ac7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068955Reviewed-by: Junliang Yan <junyan@redhat.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#76063}
-
Georg Neis authored
Bug: chromium:1234770 Change-Id: I7368c4bcebc9b4ae78291e9e7bfc860328a742ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068941Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76062}
-
Thibaud Michaud authored
Also introduce a separate error type for WebAssembly.Exception, since the properties should not be added to RuntimeError. R=jkummerow@chromium.org Bug: v8:11992 Change-Id: I8f4ae0da9a95184366e07dc43e58a5a9ff4382ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055304Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#76061}
-
Clemens Backes authored
This ports https://crrev.com/c/3040844 to also work on Mac. All that's needed is minor tweaks to the inline assembly. The inline assembly is stripped down to what's actually needed. I didn't find documentation on ".pushsection" and ".popsection" on Mac. Since we do not have this on other inline assembly (e.g. src/heap/base/asm/x64/push_registers_asm.cc) removing this here does not regress the status quo. If this ever causes problems, we will have to consistently add it everywhere. The new code paths are tested by the v8_mac_arm64* CQ bots, and the "V8 Mac - arm64 - sim - {debug,release}" waterfall bots. R=ahaas@chromium.org, mseaborn@chromium.org Bug: v8:11955 Change-Id: If0b78a2d2a8b365c1c77b171de0591452e4bbeec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3063500Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76060}
-
Benedikt Meurer authored
Previously the V8 inspector would only turn embedder accessors on the prototype chain into data properties, but would not do the same for ECMAScript builtins, which is kind of inconsistent and weird behavior. This leaves in the hack that the inspector reports native accessor properties as (own) data properties, but now at least the very least does so consistently. In the absence of a better solution, we'll go with this for now. Bug: chromium:1076820, chromium:1199247 Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f Before: https://imgur.com/kPuSldj.png After: https://imgur.com/eFau45m.png Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#76059}
-
Jakob Gruber authored
The current map is safe to read, and backpointers (read inside Map::FindFieldOwner) are immutable after initialization. Bug: v8:7790 Change-Id: I10329a44b8fa1e831fc2b52c0bc16c81891af784 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068949 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76058}
-
Jakob Gruber authored
Feedback is protected by acquire-release. Bug: v8:7790 Change-Id: I5b9e8f2fa8109207420dd715407c0791fe47db8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068943 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76057}
-
Liu Yu authored
Port 6bf0b704 Bug: v8:11872 Change-Id: I08a88402229e56b923a0551d64c53d73b8e909f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068323 Auto-Submit: Liu yu <liuyu@loongson.cn> Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#76056}
-
Jakob Gruber authored
Based on a CL by mvstanton@. Bug: v8:7790,v8:12030,v8:12031,v8:12041 Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76055}
-
Jakob Gruber authored
The `previous` field is immutable after initialization and the context itself is read through an atomic load. Bug: v8:7790 Change-Id: I8525cac7264573a7e9fc479613aaf268b72ab836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067333 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76054}
-
Michael Achenbach authored
This reverts commit 098835f7. Reason for revert: Testing reverts Original change's description: > [infra] Dummy change to test OWNERS enforcement > > No-Try: true > Bug: chromium:1235962 > Change-Id: I6dabb9855e5db118315c33ab106ac7ba2c4721b8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068938 > Owners-Override: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#76051} Bug: chromium:1235962 Change-Id: I5d3d865c2e8b4c69122a2b6ee6c0bcb9bd1ec6f6 No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068940 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Owners-Override: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#76053}
-