- 12 Feb, 2021 2 commits
-
-
Ng Zhi An authored
Extract code sequence for v64x2.alltrue into macro-assembler for sharing between TurboFan and Liftoff. Bug: v8:11347,v8:11348 Change-Id: I8119f5425c8cf11ddac77f69ed9e62a408f7049d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686011 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72681}
-
Ng Zhi An authored
Bug: v8:11347,v8:11348 Change-Id: Ib9eb0c8d03af9e0d9171ba668e8720332659e187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686010 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
-
- 11 Feb, 2021 36 commits
-
-
Seth Brenith authored
In https://chromium-review.googlesource.com/c/v8/v8/+/2641180 , we are discussing renaming AccumulatorUse. To avoid polluting that change with a large mechanical find&replace, I've created a separate change for the renaming. Change-Id: Ibc7e438f9e719571c9237e7e08ba86562a3c679f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684923Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72679}
-
Milad Fa authored
Port 1b81ffb1 Original Commit Message: Other archs will come later. R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I7a1194c3270486de326b74b63cefc4aded5faff5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691028Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72678}
-
Toon Verwaest authored
This speeds up sparkplug by >20%. This reland fixes the OffHeapBytecodeArray to also register a GC callback. Turns out off-heap here doesn't mean that the underlying bytecode array is off-heap and it can in fact move. Change-Id: I7c6e82abd2a7be08ead537ab84855e76edc3b290 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688400 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72677}
-
Milad Fa authored
Port 66964c51 Original Commit Message: Extract codegen into macro-assembler functions for reuse in Liftoff. Some minor tweaks in I32x4TruncSatF64x2SZero and I32x4TruncSatF64x2UZero to check dst and src overlap and move to scratch/dst accordingly. In TurboFan we can set these restrictions in the instruction-selector, but not in Liftoff. This doesn't make TurboFan codegen any worse, since those restrictions are still in place. R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: Iae59472a5e77c1becc5ff880081f2c0c8c149630 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690828Reviewed-by:
-
Sathya Gunasekaran authored
If the accessor pair is available, thread it through to the TryLookupCachedProperty function rather than looking it up again. On a simple microbenchmark[0] with --no-opt and --no-use-ic this provides a 5-10% improvement. [0]: https://gist.github.com/gsathya/c47da0a15be08062c12cda9b0887de3d Bug: v8:9805 Change-Id: I5b2d0c5e27c49a1d39a99dc63c3b0809bca4d6a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685178Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72675}
-
Ng Zhi An authored
Other archs will come later. Bug: v8:11347,v8:11348 Change-Id: I9ea656b9c7ce03c9dafb631dd67f6e2f7d4346a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686312Reviewed-by:
-
Junliang Yan authored
Change-Id: If817a6ed0e20cf71f33bbeec69118adff0ac898e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690548Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#72673}
-
Omer Katz authored
Bug: chromium:1056170 Change-Id: I6fb5278dd1ef14faac13602cd28286d0e0d29054 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689198 Commit-Queue: Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72672}
-
Santiago Aboy Solanes authored
Reasons: * We disabled it more than a year ago for all configs * Not easy to re-enable * Not compatible with pointer compression as-is * Not compatible with concurrent TP/TF as-is * No concrete plans to re-enable it Also remove Map's layout_descriptor since it was only used for double field unboxing. Bug: v8:11422 Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Michael Lippautz authored
cppgc/testing.h is already part of a testonly gn target which only can be included from other test targets. This prevents any production target to depend on cppgc/testing.h. Bug: chromium:1056170 Change-Id: I51f6c47ffac2a05c8c63d7b4663c456a64fe75b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689196Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72670}
-
Benedikt Meurer authored
The `wasmvalue` was missing from `PropertyPreview` and `ObjectPreview` subtype enums. Bug: chromium:1170282 Change-Id: If4f8aa330d81e603c82a16b19f14d037d556a373 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689197Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
-
Mythri A authored
Currently %OptimizeFunctionOnNextCall returns if there is the function is already optimized. This cl changes this function to allow tiering up till we reach top tier. That allows us to tier up from Turboprop to Turbofan using intrinsics. This cl also introduces a runtime-test function to check if turboprop-as-toptier or turboprop-as-midtier is enabled. Bug: chromium:1172797, v8:9684 Change-Id: Idbd99b816d4b93e4e619be5d4ccdfe89fc561a9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682638 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit b471bc93. Reason for revert: Seems like we don't reliably deliver scriptParsed events on reload after this CL. Original change's description: > [wasm] Send a single scriptParsed event per script > > If a script was shared between multiple modules (because they used the > same wire bytes) it could happen that we still triggered multiple > "scriptParsed" events via CDP. This was because > {WasmEngine::GetOrCreateScript} did not communicate back whether it > used a cached script or whether it created a new one. > > This CL moves the call to {Debug::OnAfterCompile} (which triggers the > "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method, > such that we only call it once per script. > Since the engine only holds a weak reference to the script, we would > still trigger multiple events if the script is garbage-collected in the > meantime. In this case there is no way around this, as the new script > would have a new ID, hence we need to emit a new event to make it > public to the debugger. > > R=thibaudm@chromium.org > CC=bmeurer@chromium.org > > Bug: chromium:1151211 > Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28 > 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_gc_stress_dbg_ng > Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755 > Reviewed-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@{#72648} TBR=clemensb@chromium.org,bmeurer@chromium.org,thibaudm@chromium.org Change-Id: I6cc299734e4fcff29289355973e7660b60b49a25 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1151211 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_gc_stress_dbg_ng Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689199Reviewed-by:
-
Ng Zhi An authored
Bug: v8:11416 Change-Id: I68bd6cade55472aed006638ea6d0c1d516d9d2cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686308 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#72666}
-
Ng Zhi An authored
Did not factor out the codegen because it is short enough (1 or 2 instructions) and will unlikely be changed (for optimization reasons). Bug: v8:11265 Change-Id: Ia79c8553ad4b3924d21f77a6064c9003dfcaeb7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689001 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Did not factor out the codegen because it is short enough (1 or 2 instructions) and will unlikely be changed (for optimization reasons). Bug: v8:11265 Change-Id: Ic5e5bc7642e80448bdaa6d130dfe7c12018eb481 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683209 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Almothana Athamneh authored
Bug: v8:11385 Change-Id: Ia1511cb68b0b38081c28d9f7c036f7589fc4ab7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689195 Auto-Submit: Almothana Athamneh <almuthanna@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72663}
-
Seth Brenith authored
Torque generates runtime accessor member functions for most class fields that are defined in .tq files, but fields with struct types are currently omitted. This change adds those accessors. As an example, if a .tq file defines the following: struct InternalClassStructElement { a: Smi; b: Smi; } class InternalClassWithStructElements extends HeapObject { const count: Smi; entries[count]: InternalClassStructElement; } Then the following accessors are generated to get and set each struct field within the 'entries' field: inline int entries_a(int i) const; inline void set_entries_a(int i, int value); inline int entries_b(int i) const; inline void set_entries_b(int i, int value); Bug: v8:7793 Change-Id: Ia40b5918e9d09f53ad8e78bc33f8629b8d6a79fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676926Reviewed-by:Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
In the latest spec, catch can take an exception index immediate, and control-flow jumps to the appropriate catch handler depending on the thrown exception. Do this by allowing multiple jump targets for the same pc in labels and in the control transfer map. At runtime, the unwinder will choose the appropriate control transfer entry based on the exception tag, unpack the exception and jump to the handler. Enable the exception cctests that were currently disabled for the interpreter, fix some issues and add tests for the new behaviors. R=clemensb@chromium.org Bug: v8:8091 Change-Id: I30cb8f9459647a7c6f7bfd9785b238a9c9e9fc10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690587Reviewed-by:
-
Omer Katz authored
HeapBase::CollectStatistics returns a HeapStatistics struct that can be used by blink to populate a memory dump. Bug: chromium:1056170 Change-Id: Ic147a02ba6b4aa77bf92cfca067da70b7e1af55b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689181 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Marja Hölttä authored
Notes: https://docs.google.com/document/d/1fEumNPCcOn4X0N5jGlAT7GQ5CEKKnw0YxLPXMoaSK5Q/edit?usp=sharing Bug: v8:11374 Change-Id: I96720c0d69fe28e7229c4c22ed3d291587b73f59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667511 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#72659}
-
Almothana Athamneh authored
Bug: chromium:1174109 Change-Id: I798fb25f97e8f5e7b38b71ea482b1ec779d0a31a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689186 Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Reviewed-by:
-
Michael Lippautz authored
WrapperDescriptor is used to describe how JS wrapper objects can be inspected to find C++ wrappable objects. In addition, to specifying which embedder fields are used to find type and instance, the descriptor also provides and embedder id that identifies garbage-collected objects. It is expected that the first field of the type is a uint16_t with that id. Bug: chromium:1056170 Change-Id: I9cf8d79db972f2dea023114fd5a567e89a3bf373 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688399Reviewed-by:
-
Ulan Degenbaev authored
Bug: v8:9380 Change-Id: I31d825265d283627406d4b976c8ab067eb7d2c06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154798 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#72656}
-
Marja Hölttä authored
Bug: v8:11340, chromium:177058 Change-Id: I34f400bc4d66275eb2fed082f1d44eccf21839d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689187Reviewed-by:
-
Pierre Langlois authored
Bug: v8:11361 Change-Id: Ie36b612907fab01c269567e901494d2c7ea01b6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689192Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#72654}
-
Benedikt Meurer authored
This bug was flushed out while working on refactoring the stack traces (as part of https://crrev.com/c/2689183). Bug: v8:8742 Change-Id: I5bbd4066cc464b71f4d9a7c90acc35e8cef7afb3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689193 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72653}
-
Jakob Gruber authored
This is a reland of da785659 The reland overrides ShouldHaveBeenSerialized for typed array refs to avoid disabling related optimizations when direct heap access is enabled. Original change's description: > [compiler] Don't serialize JSTypedArray fields > > This CL removes serialization of JSTypedArray fields when direct heap > reads are enabled. Invariants we rely on: > > - Of the underlying interesting fields, > - base_pointer and external_pointer are set either during > initialization, or in a one-time on-to-off-heap transition in > GetBuffer. > - length and buffer are immutable after initialization. > - is_on_heap and DataPtr derive from base_pointer and > external_pointer s.t. is_on_heap == (base_pointer != 0) and > DataPtr == external_pointer in the off-heap case. > > In this CL we add one new invariant: > > - For all base_pointer and external_pointer mutations after > initialization, base_pointer is guaranteed to be release-stored > after external_pointer has been written. > > With these invariants, concurrent access to off-heap typed arrays is > trivial as long as is_on_heap (= base_pointer) is read before other > relevant fields. > > Note that JSTypedArray remains a kSerializedHeapObject due to the > serialized superclass JSObject. > > Drive-by: Remove unused Torque operators and empty TODOs. > > Bug: v8:7790 > Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386 > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72572} Bug: v8:7790 Change-Id: I87b37de983e8cf89ca53b5efae7ab195781f3df5 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689182Reviewed-by:
-
Mythri Alle authored
This reverts commit 2a446a90. Reason for revert: This caused regressions on Octane / Jetstream2 / Sunspider and a couple of regressions on memory usage on mobile: https://bugs.chromium.org/p/chromium/issues/detail?id=1177124 https://bugs.chromium.org/p/chromium/issues/detail?id=1177241 Original change's description: > Enable FLAG_feedback_allocation_on_bytecode_size > > This flag enables feedback allocation heuristics to be based on the > function size. The threshold for feedback allocation is set to > 4 * bytecode size to roughly mimic the allocation after 4 invocations. > > Change-Id: Ia840cd526e3718d4267e01c688c6c6467e352d72 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685175 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Mythri Alle <mythria@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72631} TBR=rmcilroy@chromium.org,mythria@chromium.org,verwaest@chromium.org Change-Id: Ib756116aa38117c06e95c7f68d8f9ba0acd34084 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689194Reviewed-by:
-
Manos Koukoutos authored
Bug: v8:11390 Change-Id: Ief0463e81744279edd7fd045e2ff0a636bd5cbba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684365Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#72650}
-
Manos Koukoutos authored
Additional arguments are allowed along with the reference, but the targeted branch must have at least one output (corresponding to the cast reference). Bug: v8:7748 Change-Id: I17383165e4bae1cada1676c6282437e1fa71905d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685161Reviewed-by:
-
Clemens Backes authored
If a script was shared between multiple modules (because they used the same wire bytes) it could happen that we still triggered multiple "scriptParsed" events via CDP. This was because {WasmEngine::GetOrCreateScript} did not communicate back whether it used a cached script or whether it created a new one. This CL moves the call to {Debug::OnAfterCompile} (which triggers the "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method, such that we only call it once per script. Since the engine only holds a weak reference to the script, we would still trigger multiple events if the script is garbage-collected in the meantime. In this case there is no way around this, as the new script would have a new ID, hence we need to emit a new event to make it public to the debugger. R=thibaudm@chromium.org CC=bmeurer@chromium.org Bug: chromium:1151211 Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28 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_gc_stress_dbg_ng Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755Reviewed-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@{#72648}
-
Benedikt Meurer authored
For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
-
Dominik Inführ authored
Make main-thread handle allocation fail more gracefully when run on background threads. Bug: v8:10315 Change-Id: Iece9215aed21020b97fede40d78ea56b9baffac4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689184 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Deepti Gandluri authored
Bug: v8:11154 Change-Id: I71d524bb33dbc2f7583da9a7d9dc2c350b57bf51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686680 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72645}
-
Jakob Gruber authored
V8 implements a fast-path for RegExp.prototype.split which diverges from the spec: instead of creating a new sticky regexp instance `splitter` and running it in a loop, we reuse the existing non-sticky regexp without looping through each character. This works fine in most cases, but we run into issues when matching at the very end of the string. According to the spec, matches at the end of the string are impossible in @@split, but in our fast-path implementation they can happen. The obvious fix would be to remove our fast-path but this comes with high performance costs. The fix implemented in this CL adds a special flag to `exec` s.t. matches at the end of the string can be treated as failures. This is only relevant for @@split. Bug: chromium:1075514 Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
- 10 Feb, 2021 2 commits
-
-
Ng Zhi An authored
Also move it from post-mvp to mvp, since it is now in the proposal. Bug: v8:11002 Change-Id: I711ee7a92e6937948c93e6028ef018188ea4c976 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676937Reviewed-by:
-
Milad Fa authored
Vector register lane numbers on IBM machines are reversed compared to x64. For example, doing an I32x4 extract_lane with lane number 0 on x64 will be equal to lane number 3 on IBM machines. Vector registers are only used for compiling Wasm code at the moment. Wasm is also little endian enforced. On s390 native, we manually do a reverse byte whenever values are loaded/stored from memory to a Simd register. On the simulator however, we do not reverse the bytes and data is just copied as is from one memory location to another location which represents a register. To keep the Wasm simulation accurate, we need to make sure accessing a lane is correctly simulated and as such we reverse the lane number on the getters and setters. We need to be careful when getting/setting values on the Low or High side of a simulated register. In the simulation, "Low" is equal to the MSB and "High" is equal to the LSB on memory. As a result, many of the "#ifdef V8_TARGET_BIG_ENDIAN" blocks on Simd opcodes are not needed anymore as we are now simulating native behaviour. Change-Id: Idfa80cdef7382febb4311c75eb6d3e1d110141fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687756 Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Reviewed-by:
-
