- 23 Feb, 2021 40 commits
-
-
Ng Zhi An authored
Bug: v8:11086 Change-Id: I3413a6cd3e9ea6078ce014a0596c51b092e44cfe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707778Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72980}
-
Omer Katz authored
Conservative tracing of an in construction objects might enter an infinite recursion if the object holds a reference to itself. The second time we try to trace the object it will be already marked and we can bail out of tracing it again. Bug: chromium:1056170 Change-Id: I74e99ca70c83f00d47299562d291adf7ba4a5808 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715065 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72979}
-
Junliang Yan authored
Change-Id: I38197dc313b049a612fb34472db3b647990747dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715086Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#72978}
-
Andreas Haas authored
With a recent change we reserve the maximum memory size also on 32-bit platforms, up to 1GB. This change, however, caused failing tests in the cases where no maximum memory size was defined and where WebAssembly defines an implicit maximum memory size of 4GB. With this CL we do not reserve more memory than the initial size if no maximum memory size is defined. R=clemensb@chromium.org Bug: v8:11493 Change-Id: I62b62fd4faa7a480275b75421a98f73539646eab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712756 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72977}
-
Thibaud Michaud authored
The arity depends on the exception type now. Take the max over all exceptions since we only need a conservative estimate. R=clemensb@chromium.org Bug: v8:8091 Change-Id: Id5a3e12d89c5d48219e8981e16c2b679d80b67db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691051Reviewed-by:
-
Manos Koukoutos authored
WasmGraphBuilder often failed to use GraphAssembler infrastructure and went with directly invoking graph()->NewNode(). This made the code more verbose, especially in cases where effect() and control() had to be passes directly to NewNode(). This CL eliminates these invocations in obvious cases. It does not try to refactor complicated code with branches, diamond patterns, etc. Additional changes: - Define a few more operators in GraphAssembler. - Move Branch() helper in WasmGraphAssembler. - Define NumberConstant() helper in WasmGraphAssembler. - Define Merge() helper with varargs in WasmGraphBuilder. - Omit IntPtrConstant() wrapper for constant offsets of Load and Store. Change-Id: I571d5286be8881504cb2060195fbd181d1fce67d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712804Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#72975}
-
Deepti Gandluri authored
Bug: chromium:1177804 Change-Id: Ic8044fb4bfe414101edb923a9bb6e71282808e58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706351Reviewed-by:
-
Manos Koukoutos authored
Functional change: Allow rtts as exception values. Additional change: Remove liftoff subtyping TODO in anticipation of removal of full ValueType usage in Liftoff. Bug: v8:7748 Change-Id: I676a7fa6417d6e86bb148b4f5b9b086cc704928e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2714702Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#72973}
-
Thibaud Michaud authored
The flag should not be set after an exception is thrown in a runtime function. The unwinder still runs after the destructor, and should take care of setting the flag depending on the catching frame. R=ahaas@chromium.org,jkummerow@chromium.org Bug: chromium:1180690 Change-Id: I0013c90f759a5145309f6e08d61ed36aeecbac63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713103Reviewed-by:
-
Shu-yu Guo authored
Bug: v8:11375 Change-Id: I85503d4930a160026409761664e796c03de358d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707546Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#72971}
-
Thibaud Michaud authored
R=clemensb@chromium.org Bug: chromium:1180457 Change-Id: I50b776af243fa17856945fecc018a87356694a97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712242 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Follow-up from https://crrev.com/c/2649147/. There are still 2 usages of _wrapper functions in the interpreter, these are slightly more annoying to get rid of since the definitions have a ifdef for MSCV/OS_WIN. Bug: v8:11384 Change-Id: Ic5ca860678f406e1c832c99398b235707da058f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713166Reviewed-by:
-
Santiago Aboy Solanes authored
Its double methods were unused so we were using it as an ObjectData* wrapper. Bug: v8:7790 Change-Id: If6bd21fc23485f1e14aa3e71aea7c7821bd03315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715185Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72968}
-
Andreas Haas authored
R=machenbach@chromium.org Bug: chromium:1177804 Change-Id: I4d94f9eb2b06743d6cbb46757efa66d14e089502 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715186Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#72967}
-
Leszek Swirski authored
Bug: v8:11420,v8:11429 Change-Id: Id2680baf5d7db7eee342ca7b3c0cb636cacf1560 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715194 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72966}
-
Ross McIlroy authored
BUG=chromium:1180335 Change-Id: Idc2b59a4ae8298a2d8beb1dbcd3135214c6f7fdf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715191 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72965}
-
Seth Brenith authored
This change adds a new abstract type Lazy<T> which can be used to interoperate with CSA code that uses LazyNode. This new type has special code-generation rules because its generated type is not TNode<...> but std::function<TNode<...>()>. Torque code can do nothing with this type except pass it around, but passing it to the CSA function RunLazy is an easy way to execute the std::function and get back a normal value. Torque code can also create Lazy<T> values using the intrinsic function %MakeLazy, which takes the name of a macro as its first parameter, followed by arguments to that macro which will be passed when the LazyNode is evaluated. We use the macro's name because the language doesn't support taking references to macros, and implementing such a feature would be complicated. Bug: v8:7793 Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72964}
-
Victor Gomes authored
Change-Id: Iefbc2fe993ca7bed385624ecc6818c94b87f3915 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715189 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Milad Fa authored
Port 1bd29073 R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Bug: v8:11086 Change-Id: I777874397514a4cbde6b6630aff9f6804568ea95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715184Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72962}
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2601880 . Change-Id: I7ad9ca42201c49df7037e65671a50caabc1fdf98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2705256Reviewed-by:
-
Mike Stanton authored
When making inlining decisions, we are interested in CodeRef::inlined_bytecode_size(). Previously, we gated a check of this value on predicate JSFunctionRef::HasAttachedOptimizedCode(), but we removed this predicate because it only recorded a value seen at serialization time. Now, we look at attached CodeRefs "live," which means we might discover that the code is now optimized, where it wasn't at serialization time. This affects the inlining decision. This CL adds an additional check before returning a non-zero inlined_bytecode_size that the code object hasn't (already) been deoptimized. It's logical to do this, because the inlined_bytecode_size is actually a stale value at this point. Bug: chromium:1180749 Change-Id: I4d55132c5b47083413d3c6b1d934bfce6b550709 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712565 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Baseline code is, like baseline frames, now considered unoptimized, sharing this name with interpreted code. Bug: v8:11420,v8:11429 Change-Id: If1f4a41725dd0d809a4412f5d2f827d19f9628fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713102 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Clemens Backes authored
After the runtime call for dynamic tiering, the instance cache is invalidated. This was assumed to be done in {SpillAllRegisters}, but the instance is still being accessed after that call, so the instance cache register might still be set after the runtime call. R=ahaas@chromium.org Bug: chromium:1179065 Change-Id: I375e7c388e5a74789050e374db50d21c2efe27e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2714544Reviewed-by: -
Clemens Backes authored
This avoids having to check both flags in two places, and prevents people from trying to enable WebAssembly in lite mode (which would currently build, but you still would not get Wasm support). The downside is that the default value shown by `gn args --list` now sais `""` instead of `true`. R=machenbach@chromium.org, rmcilroy@chromium.org CC=ecmziegler@chromium.org Bug: v8:11238 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Change-Id: Ib2fe6c32cbdeb89895265bb898abf7284c560cc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712783 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72957}
-
Santiago Aboy Solanes authored
This is a reland of ed225df7 Reland changes: removed #if DEBUG from v8.h since it had compile errors in chromium + windows. Also wasn't needed anyway since the method it was calling was just a DCHECK. Original change's description: > [objects] Cache the ExternalString's data in its resource > > For external uncached strings (also called "Small External Strings") > with cacheable resources, we can cache its resource's data at the > string's creation time. This allows us to safely read the data from the > background as we wouldn't trigger a data() callback. > > For more information regarding the investigation and possible proposals > see > https://docs.google.com/document/d/101eAQqFpBPWFGNJicxtdlwYShJkTOUsEuxkVVeu5Hrk/edit?usp=sharing > > Bug: v8:7790, v8:11463 > Change-Id: I6164092b01a6ccb525a9516f476e066b35fb1f96 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685177 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72862} Bug: v8:7790 Bug: v8:11463 Change-Id: I7c8a54c814b92c8632fb0bcf5a33f57fec159443 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710440Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Georg Neis authored
AbstractBytecodeArray was introduced in order to let the bytecode array accessor work on either a Handle<BytecodeArray> or a serialized BytecodeArrayRef. We have since implemented direct heap access for bytecode arrays, so we can now remove the abstraction again. Note that this means that as far as bytecode iteration is concerned we no longer access the bytecode array through the BytecodeArrayRef. I will remove the obsolete methods from that class in a follow-up CL. The downside is the loss of this explicit interface. The upside is simplicity and less code. We can justify the downside with the fact that the bytecode array data is immutable and thus the Ref indirection less meaningful than in other cases. Bug: v8:7790 Change-Id: I0fe87b4efd0f77785f5a0917ab213c6031d9cc74 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707166Reviewed-by:
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL adds printing and verification functions. Bug: v8:11388 Change-Id: I6af8672f19589f5693ebafbcafb8d59b26749eef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704669 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Michael Achenbach authored
No-Try: true Bug: v8:11338, v8:11413 Change-Id: I5a3365e557bc3727071d8d73e9b3f9da1ae6d011 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2714704 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72953}
-
Jakob Gruber authored
.. which can return Undefined if reading out of bounds, so the return type is ObjectRef and not StringRef (if we had torque-like union types it'd be StringRef|OddballRef). Also change the function name to GetCharAsStringOrUndefined. Bug: v8:7790,chromium:1181246 Change-Id: Icf9e8fd03d11c3936e87a509b9117e547972d283 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712965Reviewed-by:
-
Clemens Backes authored
If two call instructions were generated right after each other, the source position table could get populated with two entries for the same PC (triggered by the follow-up CL: https://crrev.com/c/2697359). This CL fixes that by slightly changing the carry-over of source positions from nodes to instructions. The call node which has a source position attached generates two instructions: 18: gap () ([rax|R|tp] = v16(-); [rbx|R|t] = v17(-);) [rax|R|t] = ArchCallWasmFunction [immediate:4] #-1 [rax|R|tp] [rbx|R|t] [immediate:5] 19: gap () () ArchJmp [immediate:6] Those are then reversed, and the source position is attached to the first one (the ArchJmp). After reversing it again later, the source position will be set to the pc *after* the call instruction, which in the example happened to be just another call instruction which already had a source position, resulting in this code: [...] 0x388ee467d426 66 e875feffff call 0x388ee467d2a0 ;; wasm stub: WasmThrow 0x388ee467d42b 6b e850feffff call 0x388ee467d280 ;; wasm stub: WasmStackGuard [...] Source positions: pc offset position 6b 5 6b 0 By attaching the source position to the *last* instruction (after reversing), we ensure that it will be generated for an instruction *before* the call, or the call itself if this is the first instruction emitted for that node. R=jgruber@chromium.org Bug: v8:11490, v8:11496 Change-Id: Ie95c87d0d9daea56ca14a811abcd02ac07a4cf84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697358 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Bug: v8:11420 Change-Id: I9f6b60381c08697d753758a9c667e588dd0599bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704677 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#72950}
-
Leszek Swirski authored
maintain hash table invariants (that equality implies matching hashes), the CodeEntry hash shouldn't include the tag either. CodeEntry: :IsSameFunctionAs does not consider the CodeEntry's tag, so to Change-Id: I1e06707b72d49ad9e88368ae68e7ccb16c2483ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712786 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72949}
-
Marja Hölttä authored
Also fixes existing tests which were asserting the wrong behavior (that setting writable=false won't have an effect). The bug was introduced by https://chromium-review.googlesource.com/c/v8/v8/+/1442640 . Bug: chromium:1158138 Change-Id: I2d85721848eb4e7d530a980a9ecef7f8693bb9a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691050 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
The main thread isolate may live until the end of the process, in which case we would not record the counts. Sample at each event instead. R=ahaas@chromium.org Bug: v8:8091 Change-Id: I5b1eb023e4ca5410c7d8f4212ff20410044bf4f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710433 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
Remove from: * Smi * RawPtrT * Oddball * Float32T * Float64T * IntPtrT * WordT * Word32T Bug: v8:6949, v8:11384 Change-Id: Ia79fdedd23cd09c49ada05d031a04a1a48c2d9c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712784Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72946}
-
Clemens Backes authored
The v8_enable_webassembly=false configuration will not be a able to run any wasm code, hence remove the whole asm to wasm translation from the binary. In order to skip specific unit tests in that configuration, we move the definition of the v8_enable_webassembly gn argument from BUILD.gn to v8.gni, such that it is available in all gn files. R=ecmziegler@chromium.org, machenbach@chromium.org Bug: v8:11238 Change-Id: Id4e290df3e42ffd2f05c377bdd3a368871815daf Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712562 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#72945}
-
Ross McIlroy authored
BUG=chromium:1180335 Change-Id: If734282bb58b4c2f5832082319f9f58962552049 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712746 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Dan Elphick authored
Since gtest_prod.h is in a test-only build target, that target cannot be a dependency of non-test build targets. To prevent gn check errors warning about, this add "// nogncheck" to any includes. Bug: v8:7330 Change-Id: I40de6983e30234de2a778780a9ca839aee0bc8ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712747 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Clemens Backes authored
This moves all tests that construct a wasm module (and load wasm-module-builder.js) from test/regress to the test/regress/wasm directory. This will make it easier to skip them all in the v8_enable_webassembly=false configuration. R=ahaas@chromium.org Bug: v8:11238 Change-Id: Ib22b0fb40a58f213182e68b78b34041651c436d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712243Reviewed-by:
-
Jakob Gruber authored
The experimental engine struggles to compile this large pattern. Change-Id: I0abd5c7ed9f6f62b1c18b5c3dc1cb6a25e130c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712754 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
