- 04 Aug, 2021 30 commits
-
-
Milad Fa authored
Port 6e474ae9 Original Commit Message: This CL is a port of https://crrev.com/c/3045349 for ia32 and arm, adding helper methods to drop arguments from the stack. R=pthier@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I7099bd98285eb22cc1cbf3abd634b3479fe9e9d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3072539Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#76099}
-
Clemens Backes authored
The number of arguments for the LiftoffCompiler has grown significantly since its initial implementation, and it becomes hard to keep track of all options at the call sites. This CL refactors all optional parameters into a {LiftoffOptions} struct which has a factory-like interface. This will allow us to add more options in the future, e.g. for dynamic tiering. R=thibaudm@chromium.org Change-Id: I66697bb2f99b676a84c158304cc3a285e1b077d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069148 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#76098}
-
Benedikt Meurer authored
For inline scripts that have a `// #sourceURL=foo.js` annotation, the V8 inspector (and by extension `Error.stack`) currently operates in terms of the `foo.js`, i.e. doesn't give any hint about the actual source, except for the line/column offsets reported upon scriptParsed. However in case of stack frames (i.e. as part of `Error.stack` or as part of the call frames reported via CDP), the line/column offsets are relative to the actual source instead of relative to the `foo.js` part, which - besides other things - makes post-processing of recorded stack traces tricky (sometimes impossible). This change adjusts the source positions reported for (inline) scripts with sourceURL annotations to be relative to the (inline) script instead of the surrounding document. Bug: chromium:1183990 Fixed: chromium:578269 Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#76097}
-
Thibaud Michaud authored
R=jkummerow@chromium.org Bug: v8:11992 Change-Id: I9fd1eabf70408f6abc4480c999ac26bf5d8ccd8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067321 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#76096}
-
Patrick Thier authored
This CL is a port of https://crrev.com/c/3045349 for ia32 and arm, adding helper methods to drop arguments from the stack. Drive-by: Add RootAsOperand to ia32. Bug: v8:11112 Change-Id: I07b753d51b9fc9fc91bf09618b1315d146827123 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069157Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#76095}
-
Omer Katz authored
crrev.com/c/3069146 fixed a write barrier issue leading to a null dereference on Windows that was triggered by having the stack allocated at address below 4GB. Turns out the same can happen on Fuchsia. Bug: chromium:1230763, chromium:1056170 Change-Id: I74ba0b465c3230b4274f2c23d279c4f73183eddb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071402 Commit-Queue: Omer Katz <omerkatz@chromium.org> Commit-Queue: Anton Bikineev <bikineev@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#76094}
-
Junliang Yan authored
Change-Id: Ib5e44e60c60afdc3c3527c882056610d72ed5e7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071518Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#76093}
-
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 10 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}
-