- 26 May, 2021 12 commits
-
-
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}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d3e8244..74f9de2 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/b9af93e..fba2905 Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/767de31..da3e6cb Rolling v8/third_party/aemu-linux-x64: uDQJbkoDWGwLYtnDu3A7LnRVwsKkaFQkUWtChrVO_hYC..Hf11zqHzrfja2miAIic8j5jVjfs3rcuSFj8vUK-AVYAC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/7da48e9..3caaaaa Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/51e3708..72bc20e Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/efa4658..1ea7a15 Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/23ef295..a3460d1 Rolling v8/third_party/jinja2: https://chromium.googlesource.com/chromium/src/third_party/jinja2/+log/11b6b3e..6906af9 Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/5b8d433..e4c7c48 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a38f01b..d663c27 Rolling v8/tools/luci-go: git_revision:9cd9603def7a649cd3e29517180d6622be2fa898..git_revision:03ab00ce4982877f2d4a0b0db48cd355e5ca65ab Rolling v8/tools/luci-go: git_revision:9cd9603def7a649cd3e29517180d6622be2fa898..git_revision:03ab00ce4982877f2d4a0b0db48cd355e5ca65ab Rolling v8/tools/luci-go: git_revision:9cd9603def7a649cd3e29517180d6622be2fa898..git_revision:03ab00ce4982877f2d4a0b0db48cd355e5ca65ab TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I619a7c566f37c879da74e36601542519cc46c632 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918435Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74780}
-
Manos Koukoutos authored
BranchElimination and CsaLoadElimination interracted badly and created quadratic behavior when run together. This happened when CsaLoadElimination kept updating arguments of a Merge, and BranchElimination kept going through all of them to find the common prefix of all path conditions. Therefore, we separate BranchElimination and CsaLoadElimination in the csa and wasm optimization pipelines. Additional changes: - Split WasmOptimizationPhase from CsaOptimizationPhase. - Remove now-redundant argument from CsaOptimizationPhase::Run. - Fine-grain how statistics are measured in the wasm pipeline. Change-Id: Id166f4f7d1ea69a1a7b7ca108af4ffedbcda8abb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912779 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74779}
-
Santiago Aboy Solanes authored
Note that Arm32 is already saving the full register in https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/arm/macro-assembler-arm.cc;l=2250;drc=ec4fd32cf7f945923fa6bb332c061ecbdaaaa405 Change-Id: I1f5fe60ca350583fb4cb877ccad74f5e260c3665 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912778 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#74778}
-
Jakob Gruber authored
.. when concurrent-inlining, use direct reads instead. Two fields were changed to have a non-atomic getter and acq-rel accessors: - Map::prototype_info - PrototypeInfo::object_create_map Bug: v8:7790 Change-Id: I05e888240d73ab6e961b1048a25713ec45fb0305 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876852Reviewed-by:
-
Clemens Backes authored
For memory accesses that are statically known to be in bounds, avoid the out-of-line code for the trap handler. This makes trap handler metadata smaller, reduces code size (by avoiding OOL code), and enables more optimizations at later phases, because unprotected memory loads can be reordered and reused. Drive-by: Use {GetMemoryAccessKind} consistently. R=ahaas@chromium.org Bug: v8:11802 Change-Id: Ia824d3355a95f446a796c5b06f69ecaa1500709b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912585Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74776}
-
Jakob Gruber authored
This is a reland of 6d99f933 No changes since revert. Original change's description: > [compiler] Replace EnsureElementsTenured by IsElementsTenured > > We can't mutate heap state from the compiler thread; turn this into a > predicate and emit generic code if it returns false. > > Bug: v8:7790 > Change-Id: I6186a87e178d0c0206b6e7659fa2a41bf65fd835 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876845 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74596} Tbr: neis@chromium.org Bug: v8:7790 Change-Id: I9cfdcf9929870a8314486292bab91e83cb448410 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917605Reviewed-by:
-
Jakob Gruber authored
This is a reland of 5258364e No changes since revert. Original change's description: > [compiler] Make NativeContextRef never-serialized > > Most NativeContext elements are immutable after initialization; > additionally, we now use acquire-release semantics to load/store > elements when possible. Reading and constructing Refs for elements > is thus possible from the background. > > A few notes: > > - A few elements are not immutable; if read from the background > thread, these must use acquire-release semantics. > - Elements can be stored from generated code; these are not compatible > with bg-thread accesses. > - While elements can be read safely from the native context, the > elements themselves may still require serialization; this is done in > NativeContextRef::Serialize. > > Bug: v8:7790 > Change-Id: I12e9611a292e7dd912438c712390731a5422407d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897254 > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74604} Tbr: neis@chromium.org Bug: v8:7790 Change-Id: Ica736a4afda2be7276508fe2f734293d0b9eeaf1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917606Reviewed-by:
-
Jakob Gruber authored
This changes the test runner to automatically treat cases in which both a flag and its negation are present as a flag contradiction. Example: "--foo --no-foo". With this change it's no longer necessary to explicitly specify these trivial contraditions in variants.py. Note: since negations are created through simple string operations, bogus constructions are possible ("--nobodys-perfect" -> "--bodys-perfect"). We accept these as unlikely-to-cause-problems. Bug: v8:10577 Change-Id: Ic52a92ed1e884b495ee4136f6e2f3257cca243c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904218Reviewed-by:Michael Achenbach <machenbach@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74773}
-
Georg Neis authored
... to get better error messages. Bug: v8:7790 Change-Id: I2296e78804e243177a7e984a0284561cd41c61bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917602 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This reverts commit 916eb869. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20gcc/11805/overview Original change's description: > Reland "[wasm][bug] Fix a couple of bugs in validation of unreachable code" > > This is a reland of 4a037f87 > > Changes compared to original change: None. This seems not to create > problems after all. > > Original change's description: > > [wasm][bug] Fix a couple of bugs in validation of unreachable code > > > > Changes: > > - SetBlockType now instantiates the block's start merge with values of > > the correct type in unreachable code. > > - EnsureStackArguments now keeps the existing stack values and moves > > them over the new bottom values. > > - Drop stack size validation in Drop(). > > - Add new tests in unreachable-validation.js. > > > > Change-Id: Ie68b3d9abb0a41d1623d4a123fb526e71941c4e7 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902733 > > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#74650} > > Change-Id: Id620f7fb6677b772b0dcfd38108256384db44439 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905598 > Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74677} Tbr: manoskouk@chromium.org Change-Id: Ia24aa453735464bdd3aafca4617beabb0cbf8823 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917601 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74771}
-
Liu Yu authored
In commit 4a5adb43, mips may allocate a bit more memory than actually needed, and move the beginning of the StackSlot in order to have it aligned. After commit e639eafe, we allocated the memory that was actually needed, so we do not need extra alignment anymore. Change-Id: I4c4c01794ed1d2cc5b8c89196eae6834f0da0b6e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917578Reviewed-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@{#74770}
-
- 25 May, 2021 28 commits
-
-
Milad Fa authored
This CL assures builds with "v8_enable_webassembly = false" compile successfully. It is an addition on top of this original port: e73c7b21 Change-Id: Ic27b3006087e4d4de6fe599a9f469d1f80cf8a8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918136Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74769}
-
Junliang Yan authored
Change-Id: Ia709a1c578d05d722690c57ae44019bda4eb8d5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918213 Auto-Submit: Junliang Yan <junyan@redhat.com> Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#74768}
-
Jakob Kummerow authored
Implementation copied from d8. Gated behind a build-time flag. Can be useful for debugging issues. Change-Id: I444d625242b1fb8fe9139472a06cb1a90269401a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906233Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74767}
-
Junliang Yan authored
Change-Id: I795d45a02f49e3a0cc62ce5d87b75a1af7b2dcc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917913 Commit-Queue: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Auto-Submit: Junliang Yan <junyan@redhat.com> Reviewed-by:
-
Milad Fa authored
Change-Id: Idb38b9f97b5a507abd6f65f0d6c126255069f979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917914Reviewed-by:
-
Paolo Severini authored
Fixes an issue with tests mjsunit/compiler/call-with-arraylike-or-spread* that fail when run with the fuzzer. Bug: v8:11821 Change-Id: I6b75c065397d66062a7f552198ca92d151d89a4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917814Reviewed-by:
-
Daniel Lehmann authored
For mprotect-based write protection of WebAssembly code memory, we open {NativeModuleModificationScope}s each time a thread needs write-access to the code space. While fine-grained switching is good for security (the permission should only be granted for as short as possible, especially since it is process-wide), this can degrade performance considerably for two reasons (we measured up to 10x slower Liftoff compilation time cf. having no write protection): 1. Switching permissions with mprotect() (and likely with similar functions on non-POSIX platforms) is just inherently expensive due to the syscall, modifying page tables, and potentially subsequent TLB flushes. For a simple benchmark (compiling Unity with --liftoff-only) --wasm-write-protect-code-memory increases the number of mprotect syscalls from ~2.6-2.8k to 6-8k (!). 2. Modifying the permissions in {SetWritable()} is synchronized across threads via the {NativeModule::allocator_mutex_}. With many fine- grained permission switching requests, lock contention on this mutex incurs a very high number of futex syscalls (measured on Linux only, but the problem is likely a general one). For the same simple benchmark as above (compiling Unity), --wasm-write-protect-code-memory increases the number of futex syscalls from ~1k to 20-40k (!). Both problems are fixed in the CL here, following this simple recipe (in case we get more of these issues in the future): 1. Identify the hot syscall either via sampling-based profiling with `sudo perf record -g -F10000 d8 ...` (needs sudo for kernel stacks) and then looking into the record or a flamegraph, or with event-based profiling with `sudo perf stat -g -e 'syscalls:sys_enter*' d8 ...`. In particular, if {NativeModuleModificationScope}s are repeatedly opened (behind a function) in a loop, this can be a problem. 2. Add a scope object outside of the loop, potentially to a function upwards in the call hierarchy of the hot loop/function. 3. Remove the scope object in the innermost function/hot loop. 4. Check all callers of the hot function (which now no longer has a scope object), whether additional scopes need to be added there for correctness. The following two offenders were especially visible in the profile: - Most of the mprotect calls were coming from {PatchJumpTablesLocked}. Pulled the scope object up into {PublishCode}. - Most of the lock contention was caused by {AddCodeWithCodeSpace}. There already was a scope object up the call chain in {AddCompiledCode}. - Fixed scope inside the loop in {FreeCode} for good measure as well. 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: I89e4a1f0998f06e4d4b5e360e0bf81836d4240f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912786 Commit-Queue: Daniel Lehmann <dlehmann@google.com> Reviewed-by: -
Igor Sheludko authored
Bug: v8:11804 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Change-Id: I81ba1408fb2701450a82c4abc29d2422746af78e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917041 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74762}
-
Junliang Yan authored
Change-Id: I6d2469cdaee5a2c4bf5ce72f8a83a458d4135cc4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917573 Auto-Submit: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
-
Alessandro Pignotti authored
This patch constantize the table size, both for primary and secondary tables, whenever the table size is known to never change. By default WebAssebly tables can be grown indefinitely, but producers can specify a maximal limit. In particular, producers can specify that the initial size of the table also correspond to the maximum size, in which case the table cannot be grown and the size is constant. This is a common case, for example when generating WebAssembly from a C++ codebase the list of indirectly called function does not need, in general, to change at runtime. Change-Id: I7f6bab60841ee8eb8bdfd996c34513f69b74d5d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912586Reviewed-by:
-
Frank Tang authored
https://chromium.googlesource.com/external/github.com/tc39/test262/+log/6d353a..d454b8 Bug: v8:7834 Change-Id: I74f4e48b036385a77679b39085125e7a60c90047 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912917Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#74759}
-
Camillo Bruni authored
Note: OutOfLineRecordWrite on arm/arm64 only takes "object" and "value" as arguments. The currently can be the same and thus we don't add any additional DHCECKs there. Change-Id: I757d1f3ba9c0d0c5994ecedf26728454e32f41a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916813 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74758}
-
Georg Neis authored
This reland is a manual revert of the previous revert (commit 815bab9f). Manual due to merge conflicts. No other changes. Original change's description: > [compiler] Remove one ObjectRef constructor > > Remove the handle-taking ObjectRef constructor in favor of > (Try)MakeRef as bottleneck. > > Bug: v8:7790 > Change-Id: I3cc3a1dcef4bac53a91c573d1a532332b88c6eb4 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883664 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74593} Bug: v8:7790 Tbr: jgruber@chromium.org Change-Id: Iafc68f68df06ca9f404427d272b663c218d6550a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917039Reviewed-by:
-
Michael Lippautz authored
Switches internals of BasePage and some getters to references that are guaranteed non-null. Bug: v8:11822 Change-Id: I484c4451720dc7e04f8b89dbe4fef03a3eaf817e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917038Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74756}
-
Shu-yu Guo authored
The spec uses the CreateDataProperty abstract operation to add properties to the result object of Object.fromEntries. Confusingly, the FastCreateDataProperty Torque macro is special-cased for adding array element properties instead of generic keyed properties. The slow path for FastCreateDataProperty goes to runtime, which was being hit everytime in Object.fromEntries since the result object is not an array. This CL switches to using StorePropertyInLiteral instead, which corresponds to the CreateDataProperty spec operation, and also has fast paths that stay in CSA. Bug: v8:11814 Change-Id: I72a6809bde556f0888806307816e200bd47edf8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2915755Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74755}
-
Milad Fa authored
After https://crrev.com/c/2905605, input type might also be a register in which case different number of instructions get emitted. The number also changes if constant pool is disabled. Port: 54d84cf3 Change-Id: I9a7adb02de55caebaad552c1e15440c97b4384b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914055 Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
-
Georg Neis authored
This was missing for transitioning stores. Bug: chromium:1209558 Change-Id: Ib75d919ef748cffd12f0add09ac2718f434eb684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916815Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74753}
-
Michael Lippautz authored
ResetLinearAllocationBuffer() must be called as part of the marking phase as it may free the current LAB which decreases live bytes which previously could have caused an underflow. Bug: chromium:1056170 Change-Id: I8a641fe340f5faf0dfad32cda84f796d0537134b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917034 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
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:
-
Ulan Degenbaev authored
The test performs manual GC with custom GC flags. Bug: v8:11820 Change-Id: I717411b3c32e468066060e8c4cb8b794a2fe219f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917035 Auto-Submit: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74750}
-
Ulan Degenbaev authored
This is a reland of 83c11a30 Original change's description: > [test] Re-enable test-heap/OutOfMemory* test > > The underlying issue was fixed in > https://chromium-review.googlesource.com/c/v8/v8/+/2505724 > > Bug: v8:7605,v8:8296 > Change-Id: I4a35fd4b73f86934a9d1339655433e2d4c26bd53 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912890 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74729} Bug: v8:7605 Bug: v8:8296 Change-Id: I734ad0424d8432d01bf1d1701a232f4535b32569 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916817 Auto-Submit: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74749}
-
Michael Lippautz authored
HeapRegistry requires a valid PageBackend for querying containment. Reorder fields to guarantee that a backend is indeed available. Bug: chromium:1056170 Change-Id: I32c0251d67ff99cd3609946154526f648c16c617 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916818 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This tests the hypothesis that the current timeout problems are on Bionic bots only. Bug: v8:11818 Change-Id: I68f84cda52ca392fbda5a400eb2bf136b7ee85a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916816 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74747}
-
Camillo Bruni authored
Enable more complex tooltips with clickable links and references. - Use short filename for Script.name if they are unique - Use shared App.isClickable method - Remove various toStringLong methods - Rename CodeLogEntry.disassemble to .code - Add DOM.button helper Bug: v8:10644 Change-Id: I5d46ffd560b37278dc46b8347cb9ff0a7fdfa2ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916373Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74746}
-
Georg Neis authored
Change-Id: I6e8f1023c761b94f6e2f6dc985a10f58056667d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916814 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#74745}
-
Igor Sheludko authored
This is a first step towards supporting unwrapped WasmObject objects on JavaScript side. In addition this CL 1) introduces Representation::WasmValue which is used for all WasmObject fields exposed to JavaScript side. 2) adds creation of meaningful DescriptorArrays for WasmObject's Maps. Bug: v8:11804 Change-Id: I4afcd39da5cb77b659943da54a2ca34d13bcc9bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912776 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Victor Gomes authored
Bug: chromium:1192162 Change-Id: Ida55f1b9f8543177851a2d037b576fc33c44b807 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912581Reviewed-by:
-
Clemens Backes authored
There are two different limits for the maximum memory size in WebAssembly: 1) A 4GB limit which is the same on all platforms, and is observable for JS programs. It is used to limit the allowed declared maximum size of a wasm memory. 2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise) which can be further limited using a command-line flag. This limit is used whenever actually allocating or growing a wasm memory. This limit is not directly observable, but we make sure that no wasm memory will ever be bigger than this limit. The second limit is the one we should check against when allocating or growing memory, while the first limit should be used when validating a module (or the parameters for WebAssembly.Memory). The compiler can rely on no memory being bigger than the second limit, which again is never bigger than the first limit. This CL adds some more documentation to the two limits, and cleans up all usages. This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime} obsolete. R=jkummerow@chromium.org Bug: chromium:1207263 Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
