- 06 Aug, 2020 1 commit
-
-
Leszek Swirski authored
Changes the isolate's string table into an off-heap structure. This allows the string table to be resized without allocating on the V8 heap, and potentially triggering a GC. This allows existing strings to be inserted into the string table without requiring allocation. This has two important benefits: 1) It allows the deserializer to insert strings directly into the string table, rather than having to defer string insertion until deserialization completes. 2) It simplifies the concurrent string table lookup to allow resizing the table inside the write lock, therefore eliminating the race where two concurrent lookups could both resize the table. The off-heap string table has the following properties: 1) The general hashmap behaviour matches the HashTable, i.e. open addressing, power-of-two sized, quadratic probing. This could, of course, now be changed. 2) The empty and deleted sentinels are changed to Smi 0 and 1, respectively, to make those comparisons a bit cheaper and not require roots access. 3) When the HashTable is resized, the old elements array is kept alive in a linked list of previous arrays, so that concurrent lookups don't lose the data they're accessing. This linked list is cleared by the GC, as then we know that all threads are in a safepoint. 4) The GC treats the hash table entries as weak roots, and only walks them for non-live reference clearing and for evacuation. 5) Since there is no longer a FixedArray to serialize for the startup snapshot, there is now a custom serialization of the string table, and the string table root is considered unserializable during weak root iteration. As a bonus, the custom serialization is more efficient, as it skips non-string entries. As a drive-by, rename LookupStringExists_NoAllocate to TryStringToIndexOrLookupExisting, to make it clearer that it returns a non-string for the case when the string is an array index. As another drive-by, extract StringSet into a separate header. Bug: v8:10729 Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69270}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 28 Jul, 2020 2 commits
-
-
Leszek Swirski authored
If we're close to a stack overflow when starting a script compile, we may get into a state where main-thread compilation would stack overflow, but background-thread compilation wouldn't. This triggers a failure of a CHECK under --stress-background-compile, but isn't actually an interesting failure. So, we loosen this CHECK to allow the main-thread having a stack overflow (strictly speaking, a RangeError) to count as a "success" for the purposes of comparing against a background compilation success. Bug: v8:10757 Change-Id: I7d687b52d178973b421c42ca0d89b4da0357232a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320649 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69092}
-
Camillo Bruni authored
Isolate::PromiseHasUserDefinedRejectionHandler no longer descends recursively the outer_promise chain but uses an std::stack to avoid stack overflows with very long promise chains. Change-Id: Icdf86a34d89b734adc7139357b2ba6b37a7882ad Bug: chromium:1096139 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316298Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#69090}
-
- 22 Jul, 2020 1 commit
-
-
Nico Hartmann authored
This CL makes the ScriptContextTable concurrently accessible from the background thread (in particular ScriptContextTable::get_context). A cctest is added to check synchronization with tsan. Bug: v8:7790 Change-Id: I2e2dc8c6a7cfa369787959c4d5ed5f357f4720fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260567Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68979}
-
- 06 Jul, 2020 1 commit
-
-
Leszek Swirski authored
This will allow it to take an OffThreadIsolate in the future, without requiring GetIsolate on SharedFunctionInfo. Change-Id: I7db56d5f0587585f829b26e60683c133760d8ff1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282534Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68696}
-
- 23 Jun, 2020 1 commit
-
-
Clemens Backes authored
The interpreter is not used in production code any more, hence move it from src/wasm to test/common/wasm. It's still used in unit tests, cctests, and in fuzzers. Because of this move, a few more methods had to be exported via V8_EXPORT_PRIVATE. R=ahaas@chromium.org, yangguo@chromium.org Bug: v8:10389 Change-Id: If626b940a721146c596fd7df4faaea633e710272 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257226 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#68480}
-
- 22 Jun, 2020 1 commit
-
-
Dan Elphick authored
This changes black/white list to block/allow list. Bug: v8:10619 Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68464}
-
- 15 Jun, 2020 1 commit
-
-
Yang Guo authored
R=szuend@chromium.org Fixes: chromium:718827 Change-Id: I261ce2cf692b5bcf88f4f7f67249ec49c837de4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241521Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#68337}
-
- 10 Jun, 2020 3 commits
-
-
Ng Zhi An authored
Making them private was a way to hide the functions, we can explicitly delete them, which give a better compilation error message as well. Also see: https://stackoverflow.com/q/55205874 Bug: v8:10488 Change-Id: I3d3227c3a87ee4de983b0d4a52f46203729b99f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233983Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#68308}
-
Manos Koukoutos authored
As per the latest update to the 'reference types' wasm proposal, the nullref type is removed. Following that, all its uses in V8 were also removed. This CL: - Removes now dead code referencing nullref. - Changes names of functions/exceptions containing 'nullref' to 'null'. - Changes nullref to the corresponding nullable type in some tests. Bug: v8:7748 Change-Id: I5b4606671d7b24dd48a45a3341e8a1c056fcd1d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238026 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68283}
-
Leszek Swirski authored
Remove error reporting from parsing::Parse*, since in most cases we didn't actually want them (clear errors afterward), and there was an issue where Compiler::Compile would try to report errors already reported in ParseAny, which ended up triggering unreachable code. As a drive-by, move some one-off parse exception handling in test-parsing into a CHECKED_PARSE_PROGRAM macro which replaces all the "necessarily positive" calls to parsing::ParseProgram. Bug: chromium:1091656 Change-Id: I4d463ec363312aea36ab92f1322cf66a416b9888 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237134Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68281}
-
- 09 Jun, 2020 1 commit
-
-
Manos Koukoutos authored
The reference types wasm proposal dropped all subtyping. Subsequently, the 'anyref' type was renamed to externref. This changes all references of the *type* anyref to externref. Additionally, the flag that permits this extension is renamed to "reftypes" to mirror the proposal name. Bug: v8:7748 Change-Id: Icf323f13b9660fd10540e65125af053fca3a03f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232941 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#68270}
-
- 03 Jun, 2020 1 commit
-
-
Mythri A authored
This is a followup of the cl [1] that fixes a bug where bytecode was getting flushed when allocating feedback vector. The fix added IsCompiledScope before allocating a new feedback vector. We now pass IsCompiledScope to JSFunction::EnsureFeedbackVector. This makes it explicit that EnsureFeedbackVector expects a function that is compiled and the bytecode shouldn't be flushed during the allocation.Also adds a test. [1] https://chromium-review.googlesource.com/c/v8/v8/+/2218066 Bug: v8:10560 Change-Id: I552c449a57555dffa625b2e4efa04c2c276fc0b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222347 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68142}
-
- 02 Jun, 2020 2 commits
-
-
Clemens Backes authored
The SourcePositionTableBuilder unconditionally allocates heap memory for every Liftoff compilation. This shows up with 1-2% of compilation time in profiles. Hence move the vector contained in the SourcePositionTableBuilder into the compilation zone. Such a zone already exists for both Liftoff and TurboFan, so we can easily save allocations this way. R=thibaudm@chromium.org Bug: v8:10576 Change-Id: Ia83d05cc8c36c775ebff6ec2064e9c3f8cc4d384 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2224221 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68112}
-
Clemens Backes authored
This adds support for multiple isolates sharing the same module but setting different breakpoints. This is simulated by having a debugger test that runs in the "--isolates" variant, i.e. two isolates running the same test at the same time. Both isolates will set and remove breakpoints. The DebugInfo will keep a separate list of breakpoints per isolate, and when recompiling a function for debugging it will respect all breakpoints in all isolates. In order to ensure consistency if multiple isolates are setting or removing breakpoints simultaneously, we go back to a more coarse-grained locking scheme, where the DebugInfo lock is held while re-compiling Liftoff functions. While recompilation will install the code in the module-global code table and jump table (and hence all isolates will use it for future calls), only the stack of the requesting isolate is rewritten to immediately use new code. This is OK, because other isolates are not interested in the new breakpoint(s) anyway. On {SetBreakpoint}, we always need to rewrite the stack of the requesting isolate though, even if the breakpoint was set before by another isolate. Drive-by: Some fixes in SharedFunctionInfo in order to support setting breakpoints via the Debug mirror. R=thibaudm@chromium.org Bug: v8:10359 Change-Id: If659afb273260fc5e8124b4b617fb4322de473c7 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218059Reviewed-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@{#68096}
-
- 20 May, 2020 1 commit
-
-
Gus Caplan authored
Math.random, while technically not having any effects which modify the surrounding JS state, does observably change between a no-side-effects evaluation and an actual evaluation, and can cause confusion. Change-Id: I4a41ac6fd3153a14245d5940fe52ada43ca05e0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207805Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Gus Caplan <me@gus.host> Cr-Commit-Position: refs/heads/master@{#67927}
-
- 13 May, 2020 2 commits
-
-
Clemens Backes authored
Frames that have not been compiled by Liftoff for debugging are uninspectable. Instead of reporting an empty local scope and stack scope in this case, just don't report these two scopes at all. This also fixes a case missed in https://crrev.com/c/2196349, where we would still try to generate the stack scope for non-debugging code. Drive-by: Use {WasmFrame} instead of {StandardFrame} in the {DebugWasmScopeIterator}, and use the {FrameInspectionScope} consistently. R=thibaudm@chromium.org, bmeurer@chromium.org CC=kimanh@chromium.org Bug: v8:10359, chromium:1071757, chromium:1079328, chromium:1072839 Change-Id: I3a3731a0bd9f582f94458500252922b4146e394f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198982Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67777}
-
Camillo Bruni authored
This CL locally improves Number.toString by 5% for the slow case where the number is not found in the cache. - Introduce NumberCacheMode to avoid needless querying of the cache - Allow for some more inlining Bug: v8:10477 Change-Id: I4163e85db587ab3a6e89c126f81f6095fdb02b2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172793Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67768}
-
- 11 May, 2020 1 commit
-
-
Clemens Backes authored
Also, rename the WASM_COMPILED frame type to just WASM. R=jkummerow@chromium.org Bug: v8:10389 Change-Id: I71f16f41a69f8b0295ba34bd7d7fad71729546f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187613 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67698}
-
- 08 May, 2020 1 commit
-
-
Clemens Backes authored
All wasm code is compiled now. Hence merge the {WasmCompiledFrameSummary} into {WasmFrameSummary} and remove the dispatch. Also, rename {IsWasmCompiled} to {IsWasm} and {AsWasmCompiled} to {AsWasm}. R=jkummerow@chromium.org Bug: v8:10389 Change-Id: I33e413c7d0fa622249563091925b29631472b40c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187170Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67689}
-
- 07 May, 2020 1 commit
-
-
Clemens Backes authored
Currently WebAssembly breakpoint information survive disabling and re-enabling the debugger. This is different from JavaScript, where they are all removed. The frontend is expected to re-set the breakpoint then. Thus this CL remembers all wasm scripts where breakpoints have been set in the Debug object, and clears them all when the debugger gets disabled. R=bmeurer@chromium.org Bug: v8:10403 Change-Id: I5f8a8f3123727c954921920897ee7bf3b73f0ae8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184969 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#67639}
-
- 06 May, 2020 3 commits
-
-
Junliang Yan authored
Bug: v8:7703 Change-Id: If2d5c2da1d653247f49e5dfb2e50850b97119b20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170798Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67629}
-
Leszek Swirski authored
Move rewriting, scope analysis, and internalization, to be unconditional operations done after parsing rather than a separate compile phase. This removes some of the complexity about rememberering when to call Compiler::Analyze, and makes these paths a bit more uniform. Also, forbid allocating any more AST strings after AstValueFactory internalization, by nulling out the Zone. Add an InternalizePartial method which doesn't null out the zone for those cases where we do want to be able to allocate after internalizing (e.g. internalization before scope analysis). Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67608}
-
Clemens Backes authored
Interpreter entry compilation was removed in https://crrev.com/c/2172962. This CL removes the {WasmInterpreterEntryFrame} and the corresponding {WASM_INTERPRETER_ENTRY} code kind. Some follow-up cleanups are left as TODOs. R=jkummerow@chromium.org,bmeurer@chromium.org Bug: v8:10389 Change-Id: I1a43eba1ac1a751e05990c688088d99fc901231f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182456Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67607}
-
- 05 May, 2020 2 commits
-
-
Philip Pfaffe authored
Wasm modules generated by emscripten today have two ways to point to debug symbol files, the source mapping url and external debug info custom sections. To support both, this CL extends CDP to appropriately report the symbol type and location. Bug: chromium:1064248 Change-Id: I9076034f6d73901d8a9c5cfd7c2988fb30bb14c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116208Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Cr-Commit-Position: refs/heads/master@{#67571}
-
Philip Pfaffe authored
Allow the DevTools frontend to evaluate variables in a wasm frame context by reusing the existing Debugger expression evaluation API. Where previously the API expected JavaScript expressions, which would in general just fail, now the expression is expected to be base64 encoded Wasm that creates a JSON string in linear memory. Bug: chromium:1020120 chromium:1068571 Change-Id: I4b31fdb9d3b21b4e08c4995ec2f07880923959e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087396Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Cr-Commit-Position: refs/heads/master@{#67568}
-
- 04 May, 2020 1 commit
-
-
Ng Zhi An authored
Bug: v8:10347 Change-Id: I5a64a9e90ec7e0f3f0baf032f2d6801a94c08a3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168026Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67547}
-
- 01 May, 2020 1 commit
-
-
Seth Brenith authored
Any function with heap-allocated variables starts by creating and pushing a new context for its execution. When entering the debugger due to the stack check in the beginning of InterpreterEntryTrampoline, the function has not yet had a chance to push that new context. The code in ScopeIterator currently assumes that any function which needs a context already has one by the time the debugger attempts to iterate scopes, but in this case that assumption is invalid, which can cause a null deref. This change introduces a new function ScopeIterator::NeedsAndHasContext to replace previous calls to current_scope_->NeedsContext(). This new function checks for the case where the current scope matches the closure scope but the context matches the containing context for the function, which implies that the function has not yet pushed its own context. Bug: v8:10319, chromium:1038747 Change-Id: I29636f269c44d35b68d8446769d17170eed50e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168021 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#67519}
-
- 28 Apr, 2020 3 commits
-
-
Yang Guo authored
R=szuend@chromium.org Fixed: chromium:1075763 Change-Id: I7f67cfb9c643d8f30bec808ccb2a9e1326ad1921 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170030Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67450}
-
Clemens Backes authored
This CL removes all debugging capabilities from the API provided by WasmDebugInfo: - setting and removing breakpoints - stepping - stack inspection The WasmDebugInfo is still kept, since it's used from tests to instantiate the interpreter. R=thibaudm@chromium.org, bmeurer@chromium.org Bug: v8:10389 Change-Id: I297bfc8df2104dae8b9f9f9b13078026c47698da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164791Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67418}
-
Paolo Severini authored
This changelist makes the GDB-stub actually execute GDB-remote commands, by accessing the Wasm engine state. More precisely: - class GdbServer registers DebugDelegates that receive debug notifications when a new Wasm module is loaded, when execution suspends at a breakpoint or for an unhandled exception. - Since the GDB-remote commands arrive on a separate thread, all queries from the debugger are transformed into Task objects, that are posted into a TaskRunner that runs in the Isolate thread. - class WasmModuleDebug contains the logic to retrieve the value of globals, locals, memory ranges from the Wasm engine and to add/remove breakpoints. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Test with: python tools\run-tests.py --outdir=out\debug_x64 debugging -j 1 Bug: chromium:1010467 Change-Id: I9703894620a027d3c920926db92e2ff809d84ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941139Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#67412}
-
- 24 Apr, 2020 2 commits
-
-
Timothy Gu authored
This is a reland of 29c1eab9 Original change's description: > [builtins] Clean up the use of class_name / ES5 [[Class]] > > Before ES2015, the ES spec had a [[Class]] internal slot for all > objects, which Object.prototype.toString() would use to figure the > returned string. Post-ES2015, the [[Class]] slot was removed in spec for > all objects, with the @@toStringTag well-known symbol the proper way to > change Object.prototype.toString() output. > > At the time, spec-identical handling without the use of [[Class]] was > implemented in V8 for all objects other than API objects, where issues > with the Web IDL spec [1] prevented Blink, and hence V8, to totally > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting > @@toStringTag on API class prototypes to manage the > Object.prototype.toString() output, so the legacy [[Class]] handling in > V8 has not been necessary for the past couple of years. > > This CL removes the remaining legacy [[Class]] handling in > Object.prototype.toString(), JSReceiver::class_name(), and > GetConstructorName(). However, it does not remove the class_name field > in FunctionTemplateInfo, as it is still used for the `name` property of > created functions. > > This CL also cleans up other places in the codebase that still reference > [[Class]]. > > This change should have minimal impact on web-compatibility. For the > change to be observable, a script must do one of the following: > > 1. delete APIConstructor.prototype[Symbol.toStringTag]; > 2. Object.setPrototypeOf(apiObject, somethingElse); > > Before this CL, these changes will not change the apiObject.toString() > output. But after this CL, they will make apiObject.toString() show > "[object Object]" (in the first case) or the @@toStringTag of the other > prototype (in the latter case). > > However, both are deemed unlikely. @@toStringTag is not well-known > feature of JavaScript, nor does it get tampered much on API > constructors. In the second case, setting the prototype of an API object > would effectly render the object useless, as all its methods (including > property getters/setters) would no longer be accessible. > > Currently, @@toStringTag-based API object branding is not yet > implemented by other browsers. This V8 bug in particular has been an > impediment to standardizing toString behavior. Fixing this bug will > unblock [3] and lead to a better Web IDL spec, and better toString() > compatibility for all. > > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 > [3]: https://github.com/heycam/webidl/pull/357 > > Bug: chromium:793406 > Cq-Include-Trybots: luci.chromium.try:linux-rel > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 > Commit-Queue: Timothy Gu <timothygu@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67327} Bug: chromium:793406 Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1 Cq-Include-Trybots: luci.chromium.try:linux-rel Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881 Auto-Submit: Timothy Gu <timothygu@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67361}
-
Bill Budge authored
This reverts commit 29c1eab9. Reason for revert: Causes Blink test failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222 Original change's description: > [builtins] Clean up the use of class_name / ES5 [[Class]] > > Before ES2015, the ES spec had a [[Class]] internal slot for all > objects, which Object.prototype.toString() would use to figure the > returned string. Post-ES2015, the [[Class]] slot was removed in spec for > all objects, with the @@toStringTag well-known symbol the proper way to > change Object.prototype.toString() output. > > At the time, spec-identical handling without the use of [[Class]] was > implemented in V8 for all objects other than API objects, where issues > with the Web IDL spec [1] prevented Blink, and hence V8, to totally > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting > @@toStringTag on API class prototypes to manage the > Object.prototype.toString() output, so the legacy [[Class]] handling in > V8 has not been necessary for the past couple of years. > > This CL removes the remaining legacy [[Class]] handling in > Object.prototype.toString(), JSReceiver::class_name(), and > GetConstructorName(). However, it does not remove the class_name field > in FunctionTemplateInfo, as it is still used for the `name` property of > created functions. > > This CL also cleans up other places in the codebase that still reference > [[Class]]. > > This change should have minimal impact on web-compatibility. For the > change to be observable, a script must do one of the following: > > 1. delete APIConstructor.prototype[Symbol.toStringTag]; > 2. Object.setPrototypeOf(apiObject, somethingElse); > > Before this CL, these changes will not change the apiObject.toString() > output. But after this CL, they will make apiObject.toString() show > "[object Object]" (in the first case) or the @@toStringTag of the other > prototype (in the latter case). > > However, both are deemed unlikely. @@toStringTag is not well-known > feature of JavaScript, nor does it get tampered much on API > constructors. In the second case, setting the prototype of an API object > would effectly render the object useless, as all its methods (including > property getters/setters) would no longer be accessible. > > Currently, @@toStringTag-based API object branding is not yet > implemented by other browsers. This V8 bug in particular has been an > impediment to standardizing toString behavior. Fixing this bug will > unblock [3] and lead to a better Web IDL spec, and better toString() > compatibility for all. > > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 > [3]: https://github.com/heycam/webidl/pull/357 > > Bug: chromium:793406 > Cq-Include-Trybots: luci.chromium.try:linux-rel > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 > Commit-Queue: Timothy Gu <timothygu@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67327} TBR=verwaest@chromium.org,timothygu@chromium.org Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:793406 Cq-Include-Trybots: luci.chromium.try:linux-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67349}
-
- 23 Apr, 2020 2 commits
-
-
Leszek Swirski authored
Move the persistent compilation state and Isolate inputs (such as the allocator, shared AST constants, hash seed, logger, etc.) which survives across both parse and compile, out of ParseInfo and into a new UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState for per-thread state such as stack limit and RCS. In particular, this new state survives the ParseInfo being destructed, which means it is available after off-thread finalization. This allows a followup to access the PendingCompilationErrorHandler after finalization and report errors on merge. Bug: v8:10314 Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67329}
-
Timothy Gu authored
Before ES2015, the ES spec had a [[Class]] internal slot for all objects, which Object.prototype.toString() would use to figure the returned string. Post-ES2015, the [[Class]] slot was removed in spec for all objects, with the @@toStringTag well-known symbol the proper way to change Object.prototype.toString() output. At the time, spec-identical handling without the use of [[Class]] was implemented in V8 for all objects other than API objects, where issues with the Web IDL spec [1] prevented Blink, and hence V8, to totally migrate to @@toStringTag. However, since 2016 [2] Blink has been setting @@toStringTag on API class prototypes to manage the Object.prototype.toString() output, so the legacy [[Class]] handling in V8 has not been necessary for the past couple of years. This CL removes the remaining legacy [[Class]] handling in Object.prototype.toString(), JSReceiver::class_name(), and GetConstructorName(). However, it does not remove the class_name field in FunctionTemplateInfo, as it is still used for the `name` property of created functions. This CL also cleans up other places in the codebase that still reference [[Class]]. This change should have minimal impact on web-compatibility. For the change to be observable, a script must do one of the following: 1. delete APIConstructor.prototype[Symbol.toStringTag]; 2. Object.setPrototypeOf(apiObject, somethingElse); Before this CL, these changes will not change the apiObject.toString() output. But after this CL, they will make apiObject.toString() show "[object Object]" (in the first case) or the @@toStringTag of the other prototype (in the latter case). However, both are deemed unlikely. @@toStringTag is not well-known feature of JavaScript, nor does it get tampered much on API constructors. In the second case, setting the prototype of an API object would effectly render the object useless, as all its methods (including property getters/setters) would no longer be accessible. Currently, @@toStringTag-based API object branding is not yet implemented by other browsers. This V8 bug in particular has been an impediment to standardizing toString behavior. Fixing this bug will unblock [3] and lead to a better Web IDL spec, and better toString() compatibility for all. [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 [3]: https://github.com/heycam/webidl/pull/357 Bug: chromium:793406 Cq-Include-Trybots: luci.chromium.try:linux-rel Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 Commit-Queue: Timothy Gu <timothygu@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67327}
-
- 22 Apr, 2020 1 commit
-
-
Leszek Swirski authored
This is a reland of e1b93a4f which was a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Give up on using C++ bitfields, go back to having base::BitField and getters/setters. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67309}
-
- 21 Apr, 2020 3 commits
-
-
Leszek Swirski authored
This reverts commit e1b93a4f. Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274 Original change's description: > Reland^4 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of 313d4844 > which was a reland of 0a59e0cb > which was a reland of 146f5375 > which was a reland of d91679bf > > Manually zero out flags with memset, since GCC appears not to initialize > the bitfield values to zero even with a default constructor. > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org > > Bug: v8:10314 > Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67271} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67275}
-
Leszek Swirski authored
This is a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Manually zero out flags with memset, since GCC appears not to initialize the bitfield values to zero even with a default constructor. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org Bug: v8:10314 Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67271}
-
Sathya Gunasekaran authored
This reverts commit 313d4844. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6354 Original change's description: > Reland^3 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of 0a59e0cb > which was a reland of 146f5375 > which was a reland of d91679bf > > Initializes the BackgroundCompileTasks's language_mode in the > constructor (previously only initialized after successful parse) in case > the parse failed. We still need to reset it after parse in case the > language mode changed (because we encountered "use strict"). > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org > > Bug: v8:10314 > Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67265} TBR=leszeks@chromium.org Change-Id: I90ac035caa76d4c4baf5ce207247d1ce5169fb2f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157370Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#67266}
-