- 26 Apr, 2021 12 commits
-
-
Clemens Backes authored
We were inconsistent in handling offsets >= 2GB on 32-bit systems. The code was still relying on this being detected as statically out of bounds, but with the increase of {kV8MaxWasmMemoryPages} to support 4GB memories, this is not the case any more. This CL fixes this by again detecting such situations as statically OOB. We do not expect to be able to allocate memories of size >2GB on such systems. If this assumptions turns out to be wrong, we will erroneously trap. If that happens, we will have to explicitly disallow memories of such size on 32-bit systems. R=jkummerow@chromium.org Bug: v8:7881, chromium:1201340 Change-Id: Ic89a67d38fb860eb8a48a4ff51bc02c53f8a2c2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848467Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74175}
-
Santiago Aboy Solanes authored
The property kInObjectPropertiesStartOrConstructorFunctionIndexOffset was set as relaxed due to races with the layout_descriptor (https://chromium-review.googlesource.com/c/v8/v8/+/555210/). The layout_descriptor was removed with the removal of double field unboxing. We are able to turn those property's accessors into non-atomic ones since they are set at construction time. Bug: v8:7790 Change-Id: I25c53f0e00718cca72ba86f8475af9ecefb7ba3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843359 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74174}
-
Leszek Swirski authored
It's unfortunate that there is both a LocalIsolate template parameter, and an actual LocalIsolate class. Clean this up by renaming the template parameters to IsolateT Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74173}
-
Jakob Gruber authored
Bug: v8:7790 Change-Id: I388a833810b3620eddcecc24fd571eda146fb785 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843353Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74172}
-
Jakob Gruber authored
Prior to this CL, Refs were defined through four lists: HEAP_BROKER_SERIALIZED_OBJECT_LIST HEAP_BROKER_POSSIBLY_BACKGROUND_SERIALIZED_OBJECT_LIST HEAP_BROKER_BACKGROUND_SERIALIZED_OBJECT_LIST HEAP_BROKER_NEVER_SERIALIZED_OBJECT_LIST Due to the way FooData objects are constructed (a long if-else chain generated from these lists), the order of entries within the lists and also between lists was important. In particular, subtypes had to appear before all their supertypes. Within one list this was doable, but with the split into 4 different lists this invariant cannot hold in practice. This CL refactors the four lists back into a single list to make observing the invariant possible with upcoming changes. The new unified list contains the RefSerializationKind as a second argument. Related changes are not very interesting, except for TryGetOrCreateData which now uses a set of templated functor objects for setup (this was necessary to handle different FooData constructor signatures). Bug: v8:7790 Change-Id: Ia4c030c767830be4253cf41e3aaf67454f1cbef6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843351 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@{#74171}
-
Patrick Thier authored
Change-Id: I1ddb64331053e969edd81debb69cc06b80c1095f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850635 Commit-Queue: Patrick Thier <pthier@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74170}
-
Mathias Bynens authored
Prior to this patch, `new RegExp('a/b')` logs the following in the DevTools Console: /a/b/ This is syntactically invalid. This patch fixes this while simplifying regular expression printing in general by leveraging `RegExp#toString`, instead of duplicating the logic on the inspector side. This is possible thanks to the recent work on making `RegExp#toString` more robust (v8:1982). Bug: chromium:1202013, v8:1982 Change-Id: I14ccc1892f4a99361ad170fea608ace630740991 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848463 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#74169}
-
Ulan Degenbaev authored
This restores the check that was removed in https://chromiumcodereview.appspot.com/12300020/ Bug: chromium:736643 Change-Id: I82e218b9f2572953a7f433d713dff0528574eea1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848469Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74168}
-
Michael Achenbach authored
No-Try: true Bug: chromium:1199430 Change-Id: I904a81a0c3e7c66addbcd5da1e44373d6cc6c350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848478 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#74167}
-
Jakob Gruber authored
On a per-job basis, --turbo-direct-heap-access should be equal to whether concurrent inlining is enabled. We simplify involved logic by removing the flag, and replacing all access to - FLAG_turbo_direct_heap_access, and - FLAG_concurrent_inlining inside compiler/ with OptimizedCompilationInfo::is_concurrent_inlining() (or derived values). Bug: v8:7790 Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345 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@{#74166}
-
Jakob Gruber authored
.. which used to be implemented by calling BooleanValue eagerly on all seen heap objects during serialization. 1) it's wasteful to call this on every object, 2) this was blocking conversion of HeapObjectRefs to not require main-thread serialization. This CL replaces the old pattern by a thread-safe TryGetBooleanValue method, which may fail in some cases (e.g. when trying to read into a HeapNumber). Bug: v8:7790 Change-Id: I9d4ab7725231adce0b488c4c08c1f4bac78ce3c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839557 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74165}
-
Jakob Gruber authored
.. by locking the MapUpdater lock during MapData construction. Note this only applies to basic MapRef/MapData construction. Some methods, in particular MapRef::SerializeFoo methods, are not yet background-serializable in general and require more work. Bug: v8:7790 Change-Id: I473e78c82012ab6abc5a0633a4d34c4a40a3fb77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839553 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74164}
-
- 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}
-
- 23 Apr, 2021 27 commits
-
-
Milad Fa authored
This test produces different outputs when compiled with gcc. It is currently failing on PPC using gcc-8, it also has failed on riscv: https://github.com/riscv/v8/issues/174 I have also tested it with gcc-10 on x64 and it still fails. The line numbers seem to be different when compiled with gcc instead of clang. As a workaround we can force the usage of macros in one line to assure outputs are the same on either compiler. Change-Id: I36a05d0dc62dfe66bdfcf177422836cb231284b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844666Reviewed-by: Anton Bikineev <bikineev@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74162}
-
Michael Achenbach authored
Change-Id: I2618874ebf8f963f669901e55ea772413160b304 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848475Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74161}
-
Almothana Athamneh authored
Bug: chromium:934932 Change-Id: I9e7940b645cfad8da40950de86c2a5a7feedccff Cq-Include-Trybots: luci.v8.try:v8_fuchsia_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846894Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#74160}
-
Almothana Athamneh authored
Create 32 bit versions of V8 Clusterfuzz Linux64 ASAN no inline - release builder and V8 Clusterfuzz Linux64 ASAN - debug builder. Bug: chromium:1196595 Change-Id: Id6e3e4d5073b824828318a61be17d7e25e30dd8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843812Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#74159}
-
Ulan Degenbaev authored
Change-Id: Ib6036e38a145153e865059f1aeccc5cdc8c9e840 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848471Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74158}
-
Jakob Kummerow authored
Since WasmToJSWrappers are on-heap Code objects, they should use the "kCallBuiltinPointer" mechanism to call builtins. AFAICT this only affected the call_ref instruction. Bug: v8:9495 Change-Id: I2d55e8f2504787a8a92410868ced8d5ce63a5376 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846896Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74157}
-
Ulan Degenbaev authored
Currently the function normalizes only old sparse backing stores. This patch removed the age check to decouple the heuristic from GC. Change-Id: I9b7f787315b2b8facfa35358143173f7d207c8da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846897Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74156}
-
Milad Fa authored
Change-Id: Ia3d7933fc415d2756e1db1c1f96828d9e6f8c28e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848461Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74155}
-
Leszek Swirski authored
This is a reland of df4dae77 Revert reason looks like an unrelated existing flake (https://crbug.com/v8/11634) Original change's description: > [arm] Make the constant pool check deadline smarter > > Rather than having periodic constant pool checks that almost always fail > (because the constant pool deadline isn't close enough, or even because > there's no constant pool to emit at all), set a single deadline on the > first constant pool insertion which expires just before the maximum > distance to the constant pool. Constant pool checks around unconditional > jumps happen irrespective of this deadline. > > In particular, this is made possible by fixing the incorrect assumption > that the constant pool can be emitted out of order. The new assumption > (that the emission is in-order) is validated with a CHECK. > > Bug: v8:11420 > Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74141} Bug: v8:11420 Change-Id: I1cc5ca9082da26ab225dee8d8ea22c385c6cc1d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848468 Auto-Submit: Leszek Swirski <leszeks@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@{#74154}
-
Patrick Thier authored
We could end up in a baseline entry trampoline without having baseline code, because of an unhandled interaction in the debugger (discarding baseline code) and the deoptimizer. Bug: chromium:1199681 Change-Id: Ia33bb4d64903dd989728465b3d83a88b84597a8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843820Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74153}
-
Ulan Degenbaev authored
This removes atomicops_internals_portable.h and inlines atomicops_internals_std.h into atomicops.h. Change-Id: Id06cae42a277fee9379590ca755571193f9e8bbc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848462Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74152}
-
Leszek Swirski authored
The ToString intrinsic isn't used anymore, since there is now a ToString bytecode, so we can remove it. Change-Id: I5ed121ae4d117660e1ee8a64a2b30e1fb054a886 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848465 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#74151}
-
Omer Katz authored
Bug: chromium:1056170 Change-Id: Id3456a36e05379a517f5c49ea0252caa91221519 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848466Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74150}
-
Nico Weber authored
Bug: chromium:1196278 Change-Id: If80b1264f537e3828867831ac4d4dfc005a1ae8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2845243 Auto-Submit: Nico Weber <thakis@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74149}
-
Mathias Bynens authored
Prior to this patch, the RemoteObject for e.g. `/x/d` got a `description` that omitted the new `d` (`hasIndices`) flag. Bug: v8:11684, v8:9548 Change-Id: I774fbd9620c6f3f2f19b819c9009fab7cc2e3229 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848460Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#74148}
-
Nico Hartmann authored
This CL applies the following changes: - JSCallReducer no longer generates a CheckBigInt in front of the generated BigIntAsUintN. - This results in a slight change of the semantics of the latter, which now includes the necessary type check. Typer and Verifier are changed accordingly. - The BigIntAsUintN operator is now effectful, since it can now deopt. - IrOpcode::kBigIntAsUintN is now lowered in SimplifedLowering instead of EffectControlLinearizer, the necessary type check is introduced by the RepresentationChanger. - Adds a small mjsunit test to check the correct deoptimization behavior of optimized BigInt.asUintN. ==> Remove UseInfo::TruncatingWord64()! Drive-by: Fix an issue in ChangeUnaryToPureBinaryOp when the new_input is at index 1. Drive-by: Introduce an %Is64Bit() intrinsic to allow tests to distinguish 32 and 64 bit architectures. Bug: v8:11682 Change-Id: I448f892d3bd2280d731ae5b248c833de8faf1bd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843816 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74147}
-
Ulan Degenbaev authored
Change-Id: Ibfbb306d52092bc9e9564d1e1b2d1cb7f7edfbb9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844662 Auto-Submit: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74146}
-
Georg Neis authored
Bug: chromium:1195650 Change-Id: Ia18c053d54aa62ecafc387688dfb57ee63d2a09c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831490Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74145}
-
Sathya Gunasekaran authored
This reverts commit df4dae77. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20-%20debug/18512/overview Original change's description: > [arm] Make the constant pool check deadline smarter > > Rather than having periodic constant pool checks that almost always fail > (because the constant pool deadline isn't close enough, or even because > there's no constant pool to emit at all), set a single deadline on the > first constant pool insertion which expires just before the maximum > distance to the constant pool. Constant pool checks around unconditional > jumps happen irrespective of this deadline. > > In particular, this is made possible by fixing the incorrect assumption > that the constant pool can be emitted out of order. The new assumption > (that the emission is in-order) is validated with a CHECK. > > Bug: v8:11420 > Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74141} Bug: v8:11420 Change-Id: Ib822425749df33fb22a38d317c107a523b382e01 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846899 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#74144}
-
Camillo Bruni authored
Add missing resources to mjsunit/BUILD.gn and tickprocesser test. Bug: v8:11681 Change-Id: I7ae8391f94913e376c93a40dd1f0ba16bff8dcc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844655Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74143}
-
Clemens Backes authored
JS-to-Wasm wrappers embed heap constants (like the undefined value), and those heap values are being accessed during compilation for tracing. This is not a data race, since those values are read-only. But if the isolate dies while we are compiling those wrappers, we might read from the heap after it has been free'd. Ideally we would not access the isolate or the heap at all during compilation, but delaying all tracing until the "finalization" phase is not feasible, and removing the heap value printing from tracing would significantly regress quality of this tracing. Hence this CL only fixes the actual issue: That we keep compiling wrappers when the isolate is already gone. It does so by introducing an {OperationsBarrier} per isolate that is being taken by each thread that executes wrapper compilation, and is used for waiting for background threads to finish before the isolate shuts down. Additionally, we actually cancel all compilation if a module dies (or the isolate shuts down) before it finished baseline compilation. In this state, the module cannot be shared between isolates yet, so it's safe to fully cancel all compilation. This cancellation is not strictly necessary, but it will reduce the time we are blocked while waiting for wrapper compilation to finish (because no new compilation will start). R=thibaudm@chromium.org CC=manoskouk@chromium.org Bug: v8:11626, chromium:1200231 Change-Id: I5b19141d22bd0cb00ba84ffa53fb07cf001e13cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846881Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74142}
-
Leszek Swirski authored
Rather than having periodic constant pool checks that almost always fail (because the constant pool deadline isn't close enough, or even because there's no constant pool to emit at all), set a single deadline on the first constant pool insertion which expires just before the maximum distance to the constant pool. Constant pool checks around unconditional jumps happen irrespective of this deadline. In particular, this is made possible by fixing the incorrect assumption that the constant pool can be emitted out of order. The new assumption (that the emission is in-order) is validated with a CHECK. Bug: v8:11420 Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74141}
-
Michael Achenbach authored
No-Try: true Bug: chromium:1199430 Change-Id: I2a2b04fae6c647602a1471a0c9959324e15ad37e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846890Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74140}
-
Ross McIlroy authored
BUG=v8:9684 Change-Id: Ia63928e67dd714690b4f54c14361c6ee5e81f604 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843809 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74139}
-
Omer Katz authored
Bug: chromium:1056170 Change-Id: I64d817f9c5f56c0d7ae5a68ef3f00d3149548259 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846882Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74138}
-
Alex Rudenko authored
`exectionContextId` parameter in Runtime.addBinding is not working correctly and does not have a practical use case. Therefore, deprecating it in favour of the `executionContextName` parameter that better serves the purpose of exposing bindings to isolated worlds. We expect most users to be able to migrate to `executionContextName`. Bug: chromium:1169639 Change-Id: Ic37cefa6a62501c7e903923f1f9c0da7e51326c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844652Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Alex Rudenko <alexrudenko@chromium.org> Cr-Commit-Position: refs/heads/master@{#74137}
-
Michael Achenbach authored
Bug: chromium:1154223 Change-Id: I022818764091bbc0d3b03cfd11b58f40fe8091ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846889Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74136}
-