- 21 Jul, 2021 2 commits
-
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I1a9787514e105c70ab101aa035e6ee4ae2284ba3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041434Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#75844}
-
Clemens Backes authored
This was triggered by the inspector fuzzer, which terminates execution after two seconds. This is done by triggering a termination exception via an interrupt. In this case, the runtime function should return immediately, and return the exception sentinel. This CL fixes the WasmDebugBreak runtime function to do that correctly. R=thibaudm@chromium.org Bug: chromium:1215711 Change-Id: Idf8e9769809f135b426e4d1a0ef82fae826050b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041423Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75838}
-
- 20 Jul, 2021 1 commit
-
-
Mythri A authored
This is a reland of ea55438a. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
-
- 12 Jul, 2021 2 commits
-
-
Mythri Alle authored
This reverts commit ea55438a. Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75679}
-
Mythri A authored
Currently with sparkplug we don't flush bytecode / baseline code of functions that were tiered up to sparkplug. This CL adds the support to flush baseline code / bytecode of functions that have baseline code too. This CL: 1. Updates the BodyDescriptor of JSFunction to treat the Code field of JSFunction as a custom weak pointer where the code is treated as weak if the bytecode corresponding to this function is old. 2. Updates GC to handle the functions that had a weak code object during the atomic phase of GC. 3. Updates the check for old bytecode to also consider when there is baseline code on the function. This CL doesn't change any heuristics for flushing. The baseline code will be flushed at the same time as bytecode. Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a Bug: v8:11947 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75674}
-
- 21 Jun, 2021 1 commit
-
-
Clemens Backes authored
The WasmEngine is shared across the whole process, so there is no need to store it in every Isolate. Instead, we can just get it from everywhere on any thread using {wasm::GetWasmEngine()}, which is a simple read of a global. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I13afb8ca3d116aa14bfaec5a4bbd6d71faa9aa17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969825Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75265}
-
- 10 Jun, 2021 1 commit
-
-
Jakob Kummerow authored
With the upcoming "exception handling" proposal, we have to ensure that traps are not catchable. This patch adds missing "uncatchable" annotations to traps in the C-API and table-related instructions. Fixed: v8:11813 Change-Id: I7bbd5043ede58a5315bd5117eb496ed014e79e91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953160 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75082}
-
- 02 Jun, 2021 2 commits
-
-
Deepti Gandluri authored
Bug: chromium:1190951 Change-Id: I2c314a143c77a9fee288f7822fea84f900c3059b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2921033Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#74930}
-
Jakob Kummerow authored
This instruction is a non-standard V8-only experiment for now, hidden behind the --experimental-wasm-gc-experiments flag. The motivation is to provide a way to set up non-canonicalized RTT hierarchies, to enable expressing the type system of Java-like languages in terms of WasmGC constructs. Bug: v8:7748 Change-Id: Idf1c18e9944c983f40f1e01b2032ee5fdc2fd81b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930478Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74920}
-
- 27 May, 2021 1 commit
-
-
Manos Koukoutos authored
Changes: - Add --experimental-wasm-gc-experiments flag. - Add array.copy opcode. Implement it in decoding and code generation behind the new flag. - Add WasmCodeBuilder::BoundsCheckArrayCopy. Move BoundsCheckArray to the private section. - Add WasmArrayCopy and WasmArrayCopyWithChecks builtin. - Add WasmArrayCopy runtime function. - Add WasmArray::ElementSlot. - Always print two hex digits in CHECK_PROTOTYPE_OPCODE. - In test-gc, print the thrown-error message if the function should not throw. - In test-gc, add GetResultObject with one argument. Bug: v8:7748 Change-Id: I58f4d37e254154596cdef5e78482b55260dd3782 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912729 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74806}
-
- 06 Apr, 2021 1 commit
-
-
K. Moon authored
PDFium builds V8 with MSVC and is_debug=true (which is not a configuration covered by the V8 bots). crrev.com/c/2690588 introduced a DCHECK_EQ which triggers an MSVC compiler error due to comparing a bool and a uint8_t value. This change converts the uint8_t value into a bool using "!!", fixing the MSVC error. This will unblock V8 rolls into PDFium. Example build log: https://logs.chromium.org/logs/pdfium/buildbucket/cr-buildbucket.appspot.com/8851041716432959712/+/steps/compile_with_ninja/0/stdout Change-Id: I5c365696ead7958709df145ccc2e5f796dec80ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806743 Auto-Submit: K. Moon <kmoon@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73797}
-
- 22 Mar, 2021 2 commits
-
-
Clemens Backes authored
Stepping code that is left on the stack will repeatedly call the WasmDebugBreak function. This has no observable effect, except for severe slowdown of execution. In the linked bug, we were executing at least another few million instructions in the same frame, so it appeared that it never finishes. This CL fixes that by replacing stepping code with non-stepping code if the WasmDebugBreak runtime function is called from stepping code but we are not stepping (any more). Adding a test for this is difficult, since this only has an effect on performance. R=thibaudm@chromium.org Bug: chromium:1153308 Change-Id: I02feb04a156dfe81ca76ce26f0af131c470ef7a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775575 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73567}
-
Clemens Backes authored
The frame types to skip are only used in the constructor, hence pass them as an initializer_list instead of template arguments. R=thibaudm@chromium.org Bug: v8:11384 Change-Id: I3ee57076a94514e5755f6f6541ebd9222306a634 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775574Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73562}
-
- 19 Mar, 2021 1 commit
-
-
Clemens Backes authored
If memory64 is enabled, memory.grow should consume and return an i64 instead of i32. This CL implements this for both TurboFan and Liftoff, and adds validation and execution tests at different layers. R=manoskouk@chromium.org Bug: v8:10949 Change-Id: I0b725dbd0d5767bda4609747c1f4aad163c35304 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773800Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73542}
-
- 05 Mar, 2021 2 commits
-
-
Andreas Haas authored
Adjust also the TurboFan implementation to match the style of other instructions like table.copy and table.fill. R=thibaudm@chromium.org Bug: v8:7581 Change-Id: Icad042055fc321855d7ffba6cd2245b016dbc013 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735636 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73218}
-
Andreas Haas authored
This CL implements table.fill in Liftoff. For that I also changed the TurboFan implementation to call the runtime through a builtin instead of calling the runtime function directly. This has the advantage that we don't have to convert the parameters to Smi in the generated code. R=thibaudm@chromium.org Bug: v8:7581 Change-Id: I26793509f8d44582d6a46d25d0c2fc933068f4fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735314Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#73214}
-
- 23 Feb, 2021 1 commit
-
-
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: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#72972}
-
- 18 Feb, 2021 1 commit
-
-
Clemens Backes authored
... for creating a FixedArray. Calling builtins is generally cheaper than calling into the runtime, and this also saves us a int->Smi conversion. The builtin still has the "Wasm" prefix, since it's only used in wasm for now. R=thibaudm@chromium.org Bug: v8:11453 Change-Id: I0c5b6b71ae1b07608f51e685014a0e8dc0034111 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698674Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72839}
-
- 17 Feb, 2021 1 commit
-
-
Clemens Backes authored
We made two runtime calls: The first one allocated the exception object containing a FixedArray of exception values, the second call did the actual throw. Inbetween the code was filling the values array. This CL refactors this to only allocate the FixedArray initially, fill it, and then allocate the actual exception and throw it both from the second runtime function. This avoids a WasmGetOwnProperty call to find the values array. R=thibaudm@chromium.org Bug: v8:11453 Change-Id: I091aaa5c7bfb2b5579fc92c953adf582e6cc175a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697359 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#72811}
-
- 12 Feb, 2021 3 commits
-
-
Clemens Backes authored
This CL adds support for instrumentation breakpoints in wasm. The request for "break on entry" is set on the script, and we need to keep it stored there because there might not be any instances of that wasm module yet. Once instances get created, the flag value is transferred to all instances. The flag stored there is then checked in the function prologue in Liftoff debugging code. This ensures that we will stop at the first valid break position in any function within that module. Hitting that instrumentation breakpoint will then clear the flag from the script and from all other live instances (in the same isolate). A first basic test is contained in this CL. More tests will be added later. R=thibaudm@chromium.org, bmeurer@chromium.org Bug: chromium:1151211 Change-Id: I5442d4044934988269becececc03699b850d51d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690588Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72701}
-
Benedikt Meurer authored
Following up on https://crrev.com/c/2689185, this CL significantly simplifies the whole implementation of the stack trace capturing. Before this CL, capturing any stack trace (for the purpose of the API or Error.stack) would roughly work like this: 1. The CaptureStackTrace() function uses the StackFrameIterator to walk the system stack. For each native frame it uses the FrameSummary abstraction to get all (including potentially inlined) frames. For each of those it appends a record consisting of six elements to a FrameArray (this holds pointers to the actual closures and receivers). 2. Afterwards the FrameArray is shrinked to the required size, and a new FixedArray is allocated, and initialized with new StackTraceFrame objects where each holds a reference to the FrameArray, the index of the frame, and an initially uninitialized StackFrameInfo reference. This new FixedArray is then returned from CaptureStackTrace() and either stored on a message object or provided to the API as v8::StackTrace. The new approach removes a lot of the machinery in between and directly creates a FixedArray of StackFrameInfo objects in CaptureStackTrace(). These StackFrameInfo objects are directly exposed as v8::StackFrame on the public API, and they hold the six fields that were previously stored flat in the FrameArray. This not only avoids a lot of copying around of data and creation of temporary objects and handles, but most importantly unifies and simplifies the stack frame function inside StackFrameInfo, so you no longer need to wonder which function / object might be responsible for a certain API. There's still a lot of room for improvement. In particular we currently don't cache the source position for a given StackFrameInfo (or globally), but rather recompute it every time. This is still very fast, significantly faster than the previous approach. There are some notable (potentially user visible) changes: - The CallSite#GetPosition() method now consistently returns the Wasm module relative bytecode offset for all Wasm frames (previously it'd return the function relative bytecode offset for non-asm.js Wasm frames). - The column and line numbers returned from StackFrameInfo methods are consistently 1-based now, instead of sometimes being 0-based (Wasm) and sometimes being 1-based (JS and asm.js Wasm). The only potentially noticable difference is that for CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but that was wrong and useless anyways. - CallSite#GetThis() would sometimes return the_hole, another bug flushed out by this CL. The CL also contains some other not noteworthy drive-by-cleanups. Fixed: chromium:1057211 Bug: chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#72694}
-
Thibaud Michaud authored
Sample elapsed time between two consecutive exception events of the same type (throw/rethrow/catch). This will give us an idea of how frequently exception handling features are used at runtime during the origin trial. R=ahaas@chromium.org Bug: v8:8091 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: Ic3095eeeca08d2e079a507a492f10d2efb5ecfd2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684367Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#72685}
-
- 02 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
Previously the WebAssembly debugger support completely ignored the condition on breakpoints. With this change, we check conditions (snippets of JavaScript) properly, which enables not only conditional breakpoints in the front-end, but also other features like 'Never pause here' (which simply sets `false` as condition) and log points. Fixed: chromium:1173007 Bug: chromium:1173006 Change-Id: I02c740d383378a1f4cc08134ad571bea08e9a905 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666690Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72485}
-
- 29 Jan, 2021 1 commit
-
-
Clemens Backes authored
This adds a regression test for https://crrev.com/c/2652488. The test reduces the available code space such that it would trigger an OOM condition if code is not garbage-collected. In order to guarantee garbage-collection in all configurations, an explicit interrupt check is added to the WasmDebugBreak runtime function. R=thibaudm@chromium.org Bug: chromium:1168564 Change-Id: I8fce7aa5128c9e3c9a7e2d2e7397c394fec7de85 Cq-Include-Trybots: luci.v8.try:v8_linux64_asan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_mac64_asan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652490 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#72435}
-
- 08 Dec, 2020 3 commits
-
-
Clemens Backes authored
This is a reland of ab4d9717. The original CL did a std::move before the final use of the NativeModule. PS2 removes that. TBR=petermarshall@chromium.org, thibaudm@chromium.org Original change's description: > [wasm] Pass the script ID to code logging > > We didn't pass a script ID with the code creation events for profiling. > This made DevTools lose the connection to the wasm script, hence > jumping from the profiler entry to the source did not work. > > This CL changes the timing of code logging a bit such that the script is > always allocated before logging. In the queue of code to be logged we > then also store the script ID, and finally set it on the {CodeEntry} > object. > > R=thibaudm@chromium.org > > Bug: chromium:1125986 > Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71654} Bug: chromium:1125986 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Change-Id: I2a7c5fe04fff726836b1279e3d05b1702a4efb76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578980Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71663}
-
Clemens Backes authored
This reverts commit ab4d9717. Reason for revert: UBSan issues: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/14184/overview Original change's description: > [wasm] Pass the script ID to code logging > > We didn't pass a script ID with the code creation events for profiling. > This made DevTools lose the connection to the wasm script, hence > jumping from the profiler entry to the source did not work. > > This CL changes the timing of code logging a bit such that the script is > always allocated before logging. In the queue of code to be logged we > then also store the script ID, and finally set it on the {CodeEntry} > object. > > R=thibaudm@chromium.org > > Bug: chromium:1125986 > Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71654} TBR=petermarshall@chromium.org,clemensb@chromium.org,thibaudm@chromium.org Change-Id: I03c90c77b55e770797a6d66b1d778992a047e07a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1125986 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575070Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71660}
-
Clemens Backes authored
We didn't pass a script ID with the code creation events for profiling. This made DevTools lose the connection to the wasm script, hence jumping from the profiler entry to the source did not work. This CL changes the timing of code logging a bit such that the script is always allocated before logging. In the queue of code to be logged we then also store the script ID, and finally set it on the {CodeEntry} object. R=thibaudm@chromium.org Bug: chromium:1125986 Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#71654}
-
- 26 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Scopes in V8 are used to guarantee one or more properties during its lifetimes. If a scope is not named e.g MyClassScope(args) instead of MyClassScope scope(args) it will get created and automatically destroyed and therefore, being useless as a scope. This CL would produce a compiling warning when that happens to ward off this developer error. Follow-up to ccrev.com/2552415 in which it was introduced and implemented for Guard classes. Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71425}
-
- 18 Nov, 2020 1 commit
-
-
Andreas Haas authored
There is a flag in the WebAssembly trap handler that is set whenever WebAssembly code is entered, and that is reset when WebAssembly code is left. In runtime functions we have DCHECKs in place that check the value of this flag. This flag is only needed when trap handlers are enabled though. When trap handlers are disabled, the flag is not enabled and disabled consistently. DCHECKs should therefore only check the flag value when trap handlers are actually enabled. R=manoskouk@chromium.org CC=vkont@google.com Bug: v8:10982 Change-Id: I3325f6057ff8d9c39d029ef04c55792162d927f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545708Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71261}
-
- 11 Nov, 2020 1 commit
-
-
Vicky Kontoura authored
This CL aims at avoiding compilation of the same js-to-wasm wrapper multiple times by iterating over all exported functions in the export table and replacing the wrapper for all functions that share the same signature with the function that tiered up. Bug: v8:10982 Change-Id: I721de2f48844349de8a5d12f512a74957c66a0e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527082 Commit-Queue: Vicky Kontoura <vkont@google.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71103}
-
- 06 Nov, 2020 1 commit
-
-
Vicky Kontoura authored
This CL addresses the behaviour of the tiering strategy for the case of the start function. The start function is currently called as an exported function, but never stored as one. This results in crashes if the start function tries to tier up (e.g. if the threshold for the tiering strategy is set to 1). Bug: v8:10982 Change-Id: Ic57d581022d84715621ce558988c6512c3200e30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2517698Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Vicky Kontoura <vkont@google.com> Cr-Commit-Position: refs/heads/master@{#70999}
-
- 22 Oct, 2020 1 commit
-
-
Clemens Backes authored
The offset (also called "address") passed to the atomic builtins was 32-bit until now. With memory64, we will have to also accept 64-bit values there, or at least values within the allocatable memory range. This CL thus changes the builtins to receive uintptr values instead of uint32, and pass them on to the runtime functions as double (as before). The runtime then casts them back to uintptr_t instead of uint32_t. Liftoff is extended to zero-extend the uint32 value if needed. TurboFan already passed a machine-word sized integer before. Drive-by: Rename some "address" to "offset" to make the semantics more clear. R=ahaas@chromium.org CC=manoskouk@chromium.org Bug: v8:10949 Change-Id: I66968cc99a908775156c952da46d2f26219ffb58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489685 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#70700}
-
- 21 Oct, 2020 1 commit
-
-
Manos Koukoutos authored
This trap now used for all runtime type errors thrown when interfacing with JS. Its name and message have been changed to reflect this. Additional change: Remove the trap from the list of traps used exclusively for RuntimeError (as opposed to TypeError) in wasm-module-builder.js. Change-Id: I517766837a60d94b562d4c0de922d52db786b635 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488688Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#70682}
-
- 14 Oct, 2020 1 commit
-
-
Vicky Kontoura authored
This CL adds a basic tiering strategy for the js-to-wasm wrappers. When applicable, calls to exported WebAssembly functions are initially handled through the generic js-to-wasm wrapper. If these calls through the generic wrapper reach a constant threshold, the specific (per-signature) wrapper is compiled synchronously for the function and the generic wrapper is replaced. Bug: v8:10982 Change-Id: I65e706daffb5cb6e723ce2f7b785f7ecb7b2fa7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461243 Commit-Queue: Vicky Kontoura <vkont@google.com> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#70503}
-
- 21 Sep, 2020 1 commit
-
-
Manos Koukoutos authored
Changes: - When checking if a table is a function table, check for subtyping to funcref instead of equality. - Add WasmModuleObject argument to GetFunctionTableEntry. - Implement WasmTableObject::Get/Set for all legal table types. - Factor out SetFunctionTableEntry from WasmTableObject::Set. - Write unittests and JS tests. Bug: v8:9495 Change-Id: I4f0c7a7013f17c561afb3039c5e0811634a4d313 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416387 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#70032}
-
- 18 Sep, 2020 2 commits
-
-
Manos Koukoutos authored
Changes: - Rename IsSignatureEqual -> MatchesSignature for consistency - Add WasmInstanceObject field to WasmTableObject. - Improve some error messages related to tables in function-body-decoder-impl.h. - Introduce WasmTable::IsValidTableType. Use it wherever appropriate. - Overload equality operators in HeapType to work with HeapType::Representation. - Rename DynamicTypeCheckRef -> TypecheckJSObject. - Handle WasmCapiFunctions in TypecheckJSObject. - Use TypecheckJSObject in WasmTableObject::IsValidElement. - A few more minor improvements. Bug: v8:9495 Change-Id: I2867dd3486d7c31717ac26b87a50e15cf2b898be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416491 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#70001}
-
Manos Koukoutos authored
Changes: - Extend IsJSCompatibleSignature to include typed functions. - Generalize WasmIsValidFuncRefValue to WasmIsValidRefValue, utilize DynamicTypeCheckRef. Use it in FromJS. - Extend DynamicTypeCheckRef to eqRef type and WasmJSFunction references. - Update call-ref.js test. Change-Id: I71166ab8c1e716c21e79776c561e77b443add1da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412527Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#69981}
-
- 11 Aug, 2020 1 commit
-
-
Kim-Anh Tran authored
This change adds support for skipping locations that are in a skipList on step over. This feature is useful for when we are debugging C++ applications that have DWARF information we only want to stop on every breakable location in C++, not non every breakable location on wasm level. Bug: chromium:1105765 Change-Id: Ie835b011a00cf31e0c5b2df1ac96ebd89f53d23a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339458Reviewed-by: Eric Leese <leese@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#69329}
-
- 28 Jul, 2020 1 commit
-
-
evih authored
This generic wrapper builtin is currently used only when the wasm function has no parameters and no return value. Added a new V8 flag to use this generic wrapper. Also added a JS test function for this generic wrapper. Bug: v8:10701 Change-Id: Id8cd1771f26922927363b715d8a6ffd384a143ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307240Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Eva Herencsárová <evih@google.com> Cr-Commit-Position: refs/heads/master@{#69097}
-
- 24 Jul, 2020 1 commit
-
-
Clemens Backes authored
Out of the four listed reasons, two are obsolete now, since stepping does not modify the code table any more. The first reason also cannot happen any more, since removing a breakpoint will also patch the stack of the isolate, and even if not, removing a breakpoint which is not set will have no effect (not even a stack rewriting). The same applies for the last listed reason. So overall, this code is not needed any more, since it has no effect. R=thibaudm@chromium.org Bug: v8:10611 Change-Id: I773ac2515b66e8bf66cb035c315db552024485c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316299Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69041}
-