- 16 Feb, 2021 17 commits
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit This change adds 16 new interpreter opcodes, kStar0 through kStar15, so that we can use a single byte to represent the common operation of storing to a low-numbered register. This generally reduces the quantity of bytecode generated on web sites by 8-9%. In order to not degrade speed, a couple of other changes are required: The existing lookahead logic to check for Star after certain other bytecode handlers is updated to check for these new short Star codes instead. Furthermore, that lookahead logic is updated to contain its own copy of the dispatch jump rather than merging control flow with the lookahead-failed case, to improve branch prediction. A bunch of constants use bytecode size in bytes as a proxy for the size or complexity of a function, and are adjusted downward proportionally to the decrease in generated bytecode size. Other small drive-by fix: update generate-bytecode-expectations to emit \n instead of \r\n on Windows. Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-
Victor Gomes authored
Change-Id: I9f41fc97c2ca9a1c62b1de4ee8c9878d5d69b560 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697195Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72772}
-
Toon Verwaest authored
Baseline scratch registers don't include the regular kScratchRegister (for now at least) because the rest of the system doesn't use the ScratchRegisterScope (yet). Bug: v8:11429 Change-Id: I7a2f27a814e262e5b14bd30b2ae53d53e173bcc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697194Reviewed-by:
-
Michael Lippautz authored
Lazy sweeping may have found a memory block not positioned at the head of the corresponding bucket. Such a block is not found during a subsequent free list allocation, as such allocations do not linearly walk the free list. Bug: chromium:1056170 Change-Id: I288b6ad768987705d86fc78d0aa6fe46e99417b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692822 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72770}
-
Sathya Gunasekaran authored
The current API returns a Handle<NativeContext> which can be optionally null and all the users of this API never actually checked for this null value. Previously, this wasn't a problem as all the possible JSObjects that were user visible would return a valid NativeContext but now there are wasm objects that don't have a valid constructor so don't have a NativeContext. Bug: v8:11451, chromium:1166077 Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72769}
-
Thibaud Michaud authored
When there are multiple nested catch blocks, the rethrow immediate disambiguates which catch block to take the exception from. We add a FixedArray to keep track of exceptions that are currently in scope, and compute the mappings between rethrow/catch instructions and the index to fetch/store the exception from/to in the FixedArray during pre-processing. R=clemensb@chromium.org Bug: v8:8091 Change-Id: If55242c551f42262c790b5bf3f1543a003280623 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695388 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72768}
-
Leszek Swirski authored
Change the interpreter tracing functions to be generic unoptimized code tracing functions. The type of the code is now inferred from the frame, rather than passed in. Also expands the set of gn flags to explicitly enable unoptimized tracing, with a helper gn flags for enabling it for Ignition and for baseline (both just set unoptimized tracing to be enabled for now, we could split this up in the future though), and V8 flags separate tracing Ignition and tracing baseline. Bug: v8:11420, v8:11429 Change-Id: I040c2628fe5744dcb38ef8623df3e34f9c86a5b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692817 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Andreas Haas authored
The origin trial for WebAssembly Threads is over for quite some time, WebAssembly Threads are enabled by default. The API can therefore be removed now. Bug: v8:11384 Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#72766}
-
Manos Koukoutos authored
Changes: - In graph-builder-interface.cc, move loop exit utilities in the private section. - In the same functions, remove SsaEnv argument. Always use ssa_env_ instead. - Introduce TerminateThrow, which introduces loop exits before inserting a throw node. - Introduce loop exits in the exception handling opcodes. - Introduce control_depth_of_current_catch() helper. - Drive-by: Add an optional missing 'break' in DoReturnCall. - Add some tests, improve test flags in loop-unrolling.js test file. Bug: v8:11298 Change-Id: I613352023e3e1c72a83cd389d98574758655abee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692820Reviewed-by:
-
Victor Gomes authored
- Also changes in arm and ia32 for consistency - Removes fall-through since MaybeOptimizeCode never returns Change-Id: I115cff07c7d58ac3f7d0e0feeccbd6b1b172bd53 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695392 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Omer Katz authored
On-heap hash maps in blink are limited to Member types and non-traceable types. The only exception to that is TraceWrapperV8Reference. Thus ephemerons can have non-gced traceable values. This values should not be pushed to the marking worklist since we expect everything in the worklist to be marked and not in construction (but these values don't have an object header). Instead, when getting a non-gced value we should immediately trace it. This is only relevant to ephemerons. Any other case would go through Trace(const T&) that dispatches to the TraceTrait. Blink has 1 use case of HeahHashMap from WeakMember<ScriptWrappable> to TraceWrapperV8Reference. Bug: chromium:1056170 Change-Id: Ia8f341d6bb1fc8fd3655b2be66b7814896549d1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696648Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72763}
-
Leszek Swirski authored
Pass an explicit Isolate* argument to Compiler::Compile*, rather than grabbing the Isolate from the function Change-Id: I37a38103c67305077225ea3951d36007cf07beea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696655Reviewed-by:
-
Clemens Backes authored
We will need more Smi loading for exception handling, hence refactor the existing code to reduce duplication and increase readability. R=ahaas@chromium.org Bug: v8:11453 Change-Id: If12ddf607e3aeb7ce0448d977d0d450127caf1d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692818Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72761}
-
Yang Guo authored
Change-Id: If794ddadcf7a5e1b75bc0087bc83c2d0e566503c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692191Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72760}
-
Georg Neis authored
They are a source of inconsistency and thus confusion. Bug: v8:11371 Change-Id: Ia62f6800ad85576bed1cfe10e7ad044bdbf569af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692247 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72759}
-
Benedikt Meurer authored
For stack traces, especially all stack traces exposed via the Inspector (i.e. for the purpose of async stack traces), JSFunction::GetDebugName() is still a bottleneck, even after the removal of "displayName" support. As outlined in https://bit.ly/devtools-function-displayName-removal a follow-up optimization here would be to improve the performance of the "name" lookup. Previously, it'd always use the LookupIterator combined with JSReceiver::GetDataProperty(), which in the common case would find the "name" property and the return undefined, since it doesn't invoke getters on AccessorInfos, and eventually fall through to the actual logic in SharedFunctionInfo::DebugName(). Now we had a similar situation with Function.prototype.bind(), which also needs to lookup "name" on regular function objects quite often, and what we implemented there is to just look into the DescriptorArray of the incoming function object and see if the entry for the "name" descriptor is still untouched (key is "name" and value is an AccessorInfo), and if so completely bypass the slow-path lookup via the LookupIterator. With this CL (and the optimization in https://crrev.com/c/2695386), the cost of symbolization is now significantly lower than the cost of the actual stack trace capturing, for the async stack traces in the example from https://crbug.com/1077657 as indicated by the perf profile below: ``` - 26.03% v8_inspector::AsyncStackTrace::capture + 17.34% v8::StackTrace::CurrentStackTrace - 7.27% v8_inspector::(anonymous namespace)::toFramesVector - 7.18% v8_inspector::V8Debugger::symbolize - 6.27% v8_inspector::StackFrame::StackFrame + 2.52% v8_inspector::toProtocolString + 1.88% v8::internal::StackFrameInfo::GetLineNumber 0.78% operator new[] 0.55% operator new[] ``` Bug: chromium:1077657, v8:8742, chromium:1069425, chromium:1177685 Change-Id: I38f23816295f4381f5109cc78e4856dc0b67b097 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695593 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72758}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/aca4b0d..bc28354 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e4328db..35976bf TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I98bc979135d43d7a77ef2bb8872c3b2ef044666b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696019Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#72757}
-
- 15 Feb, 2021 23 commits
-
-
Toon Verwaest authored
Those are blocked on Torque supporting LazyNode. Bug: v8:11429 Change-Id: Ie8797027dd9a4480bb254c984e8e2288ab35423b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692819Reviewed-by:
-
Toon Verwaest authored
- Directly use the right target register for the "fast" case as temporary register - Don't load the function to load the feedback since that's unnecessary by now - Deduplicate the cell loading code Bug: v8:11429 Change-Id: Ia2298315c2db6f228be0821687ff92859169dd97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695588 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Omer Katz authored
Bug: chromium:1056170 Change-Id: I561166a7f1be658c5c35aa1caf8dbbbd2d720ab3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692815 Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Add support for CodeEntry, ExceptionHandler, and tail-calls via x17, to make sparkplug code pass CFI tests. Fixed: v8:11439 Change-Id: Ic540da9d859fd981de345cf53b43ae55edd07180 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695592 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
Previously we had cached the source position information on JSStackFrame (C++) objects and reused that between calls to GetLineNumber() and GetColumnNumber(). The refactoring in https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8 effectively removed that cache, while still making things faster though. This CL puts back the caching on the StackFrameInfo objects by reusing the `offset` slot to store the computed source position (as indicated by a bit in the `flags`). For promise combinator async frames, the bit is always set and the `offset_or_source_position` slot thus always contains the source position (aka the `promise index` in this case). We also added a `StackFrameInfo::ComputeLocation()` method to remove the last remaining place where we'd peek into the StackFrameInfo from outside stack-frame-info.{cc,h}. Also-By: kimanh@chromium.org Bug: chromium:1077657, v8:8742, chromium:1069425 Change-Id: I59e26a91965617163776e6cc2610b88e6925452c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Georg Neis authored
This is a reland of 5cc7bfd0, after the dependency has relanded. Original change's description: > [compiler] Clean up ObjectDataKind > > In particular: remove PossiblyBackgroundSerializedHeapObject in favor of > either SerializedHeapObject or BackgroundSerializedHeapObject, depending > on the (existing) argument to the ObjectRef constructor. > > Bug: v8:7790 > Change-Id: I0a67872c377107799233742cc7774bea62811d0f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681946 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72591} Tbr: solanes@chromium.org, nicohartmann@chromium.org Bug: v8:7790 Change-Id: I7de88f54172078a42b5aa341b11309ac3581eed0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695589Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72751}
-
Clemens Backes authored
This removes a redundant SpillRegisters implementation in liftoff-assembler-ia32.h, and uses the existing platform-independent method in liftoff-assembler.h consistently. R=ahaas@chromium.org Bug: v8:11384 Change-Id: I20f0417c248e06557dc1fe8bab834a99257940de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695399Reviewed-by:
-
Junliang Yan authored
Port 15f3392a Original Commit Message: 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=clemensb@chromium.org, midawson@redhat.com, mfarazma@redhat.com BUG= LOG=N Change-Id: I892eec22aa804abb8b22f3bdd811664f9a2605d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695606Reviewed-by:
-
Ross McIlroy authored
This reverts commit 1370b29e. Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409. Original change's description: > [build] Enable external flag header with defines > > Due to some unusual build failures on some trybots, > v8_generate_external_defines_header was reverted to false. This turns it > back on but changes the behaviour so that defines are added to the > command line as well as to the header. Because the generated header > checks that flags that should be unset are actually unset and flags that > should be set are either unset or set to 1, this will cause build > failures on many types of mismatches, although it will not detect where a > flag is not set on the command line when it is set by the header. > > If no further failures show up with this, the hybrid part can be removed > and the v8-gn.h header can stand on its own. > > Bug: v8:11292, v8:11341 > Change-Id: I1deeeebec58f79607e68a28f808649e884810923 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72327} TBR=mlippautz@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:11292 Bug: v8:11341 Change-Id: I6cf57014ef8be73c286ad9c5ebf597915f183717 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695400Reviewed-by:
-
Toon Verwaest authored
We could revisit this later, but right now the direction we're going is simply keeping fast paths in the called builtins and not generating more custom inline code. Bug: v8:11429 Change-Id: I2e3a67e1a2a2ab62e8c785dd9bdf2de3e7215f60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695405 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Add (ToNumber|ToNumeric)_Baseline builtins which get the feedback vector and context from the stack, perform ToNumber/ToNumeric, and update feedback. These share C++ code with Builtins::kToNumber, but don't call it directly, as they need to collect feedback as part of the conversion. Bug: v8:11420, v8:11429 Change-Id: Idca1281004ec27096cbe9204653fdd72386ab52b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692573 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72746}
-
pthier authored
The check was a leftover from a debugging session. We don't have a feedback vector even though we have baseline code, e.g. when we share baseline code across realms. In this case the feedback vector will be allocated upon the first invocation of the function. Bug: chromium:1177217 Change-Id: Ia5cde35b0f5d746c2ba64d3ca2083acdfaf286bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695396 Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72745}
-
Georg Neis authored
... otherwise we'd abort at runtime. Bug: chromium:1178076 Change-Id: Ic7b4a3b27379ec0d42419e2695ab487904eabd72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695395Reviewed-by:
-
Leszek Swirski authored
Add a new StackFrame class for unoptimized frames (which are either interpreted or baseline). BaselineFrame becomes a subclass of this rather than InterpretedFrame, and the various frame constants helpers are similarly amended. Bug: v8:11420, v8:11429 Change-Id: I87e9368aef48ef06a39476bf826f379ce1441528 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692208 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Bug: v8:11420 Change-Id: I61182b0b1b3ee8d1ea55df48577077dbd3a36ec5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695397Reviewed-by:
-
Victor Gomes authored
Change-Id: I8b5c6347ab22d2578bd8975cf10b5508832fd0c0 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695398 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
R=ahaas@chromium.org Bug: v8:8091 Change-Id: I3d1053b3a11bf81ed2e58098f8429683d4e753ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690597Reviewed-by:
-
Thibaud Michaud authored
R=clemensb@chromium.org Bug: v8:8091 Change-Id: Ic01ccc2978642b70c603b1666137ad5f587a152f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690604Reviewed-by:
-
Kim-Anh Tran authored
This adds a call to re-compile top level functions in case no shared function info could be found. We ran into a bug where it was not possible to set a breakpoint on the top-level function since it was already removed by the GC. Bug: chromium:1137141 Change-Id: I5bb6984825eee8ebcb44619e15b3acf3d118b9bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672181Reviewed-by:
-
Thibaud Michaud authored
- Add missing EnsureStackSpace before unpacking the exception (decoder) - Pop current catch when delegating to the caller (graph builder) - Mark throw opcode as unconditional jump R=clemensb@chromium.org Bug: v8:8091, v8:11449 Change-Id: I702f6a99581476e77d254e2ea91f9c463ceed444 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692688 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
Also block sending "type" as part of the ObjectPreview, but only send the "value" property. The front-end will be updated to display WasmValueObject's similar to what we do for wrapper objects (i.e. StringWrapper and the like). The matching front-end change is still pending. Also refactor the WasmValueObject to have dedicated constructors for the individual types (i32, i64, f32, f64, externref and v128). This way we can just reuse the existing logic in descriptionForObject() and we also don't need to store the "type" on the object itself (not really performance sensitive, but fewer moving parts / things that can go wrong). This also addresses the crash in https://crbug.com/1166077#c16 since the WasmValueObject instances now have a proper JSFunction in their maps' constructor_or_backpointer slot and are thus able to locate their creation context. Note that this doesn't generally address https://crbug.com/1166077 itself, but only the WasmValueObject case. Screenshot: https://imgur.com/kbd3bix.png Bug: chromium:1170282, chromium:1071432 Bug: chromium:1159402, chromium:1166077 Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
-
Clemens Backes authored
Instead of looking up the register holding the instance parameter, and checking that this is the constant we expected, do it the other way around: Use the constant, and check that this matches the information in the CallDescriptor. This saves a few instructions on every Liftoff function compilation. Drive-by: Move comments, checks, and code emission closer together. R=thibaudm@chromium.org Bug: v8:11384 Change-Id: If51425479ded4f271de231479c21e24acefe7f35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692575Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72735}
-
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 swiss-hash-table-helpers.h, which contains helpers that are mostly independent from a particular swiss table implementation (like SwissNameDIctionary) and can therefore be re-used by potential other Swiss Table implementations in the future. As a consequence of that, those helpers are largely taken unchanged from Abseil. Bug: v8:11388 Change-Id: I27636731c2166cb10240b847a1d7df0412aa0a33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687752 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72734}
-
