- 14 Jan, 2022 3 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/31e7941..6cf20f1 Suppress GoogleTest warnings on windows (MSVC) too. (#1320) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/6cf20f1 Add docs on Memory profiling (#1217). (#1319) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/5531ec8 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,mlippautz@chromium.org Change-Id: I4ba1571dc6b955a3ba1ad1569300518a709dd8e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387111 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#78616}
-
Leszek Swirski authored
This reverts commit 3cb4039c. Reason for revert: TSAN failure in newly added test: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/18086/overview Original change's description: > [string] Support shared strings in Value{Serializer,Deserializer} > > When FLAG_shared_string_table is true, postMessaging strings will share > instead of copy. > > Note that not all operations on shared strings are supported, and shared > strings may be slower than non-shared strings for some operations. > > Bug: v8:12007 > Change-Id: I3462128e15410d2568868143571571b3025722c1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78614} Bug: v8:12007 Change-Id: I5bb8f9b4e9b641c6d5cb16f963e9dbc1b13ac56a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386799 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78615}
-
Shu-yu Guo authored
When FLAG_shared_string_table is true, postMessaging strings will share instead of copy. Note that not all operations on shared strings are supported, and shared strings may be slower than non-shared strings for some operations. Bug: v8:12007 Change-Id: I3462128e15410d2568868143571571b3025722c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#78614}
-
- 13 Jan, 2022 20 commits
-
-
Lei Zhang authored
Use grep to check for obviously unneeded includes. e.g. headers that include <vector> but does not contain "std::vector". Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/main@{#78613}
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I3a20c588c2e0753c646cceb0a03fd882041fed7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383779Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#78612}
-
Nikolaos Papaspyrou authored
The total wall time for GC reported to Blink is explicitly included in UMA events. For the C++ managed heap, it is equal to the sum of the four phases (mark, sweep, compact, weak). For the JS heap, it will be greater than or equal to that sum in general. Bug: chromium:1154636 Change-Id: Id710702b8e9d8db5c8d1eb4917deb6b760a77306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386596Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Cr-Commit-Position: refs/heads/main@{#78611}
-
Benedikt Meurer authored
Following up on https://crrev.com/c/3383775 we are now able to further simplify the implementation of `await` and its instrumentation (for both debugger and promise hooks), which aligns the implementation more closely with the spec text and removes a whole bunch of unnecessary code. This also moves the `await` instrumentation into runtime-debug.cc along with the other instrumentation methods for async functions. Bug: chromium:1280519, chromium:1277451, chromium:1246867 Change-Id: I3fb543c76229091b502f3188da962784977158ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386597 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#78610}
-
Junliang Yan authored
Change-Id: I7f2463e8363a060651daabc6e32fbc56405868b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387074Reviewed-by: Milad Farazmand <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#78609}
-
Manos Koukoutos authored
When initializing a table entry with null or a function constant, do not go through EvaluateInitExpression. Remove the option to treat functions lazily in EvaluateInitExpression/InitExprInterface. Drive-by: Shrink indirect tables by removing redundant field. Bug: chromium:1284557 Change-Id: I78a64becebf4b967b0a440d43855e163ec190b7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383135Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#78608}
-
Tobias Tebbi authored
Bug: chromium:1274443 Change-Id: I3f6766dc84019ae017b6da1ae797c946a33079b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3351968Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#78607}
-
Nico Hartmann authored
Bug: v8:12261 Change-Id: I4872ba82676bf64fa51d5a599323382c65cc465a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386594 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#78606}
-
Leszek Swirski authored
This reverts commit 142dd775. Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview Original change's description: > cppgc-js,heap: Implement snapshots for embedder fields > > https://crrev.com/c/3293410 added concurrent processing of C++ objects > found through V8 embedder fields. The CL missed that those embedder > fields are not read atomically from JS objects. The problem is that > embedder fields are only aligned to kTaggedSize on builds with pointer > compression and are as such mis-aligned for atomic ops. This is not a > problem for on-heap values as the upper 32bits are anyways computed > from the cage. Is is a problem for generic C++ values though, as they > are used with Oilpan. > > This CL adds the standard marker snapshot protocol for embedder fields. > > Marker: > 1. Snapshot embedder fields > 2. Try to mark host object > 3. On success: process snapshot > > Main thread: > 1. On setting embedder fields mark the object black first > 2. Emit a write barrier for the embedder fields > > This will get simpler with the heap sandbox that uses a separate table > for embedder fields. Once the sandbox is the default configuration, we > can use it as dependency for the concurrent fast path. > > Bug: chromium:1285706 > Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78604} Bug: chromium:1285706 Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#78605}
-
Michael Lippautz authored
https://crrev.com/c/3293410 added concurrent processing of C++ objects found through V8 embedder fields. The CL missed that those embedder fields are not read atomically from JS objects. The problem is that embedder fields are only aligned to kTaggedSize on builds with pointer compression and are as such mis-aligned for atomic ops. This is not a problem for on-heap values as the upper 32bits are anyways computed from the cage. Is is a problem for generic C++ values though, as they are used with Oilpan. This CL adds the standard marker snapshot protocol for embedder fields. Marker: 1. Snapshot embedder fields 2. Try to mark host object 3. On success: process snapshot Main thread: 1. On setting embedder fields mark the object black first 2. Emit a write barrier for the embedder fields This will get simpler with the heap sandbox that uses a separate table for embedder fields. Once the sandbox is the default configuration, we can use it as dependency for the concurrent fast path. Bug: chromium:1285706 Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78604}
-
Seth Brenith authored
Change-Id: I7cf964294304c380fb285eebf1e65b0f84dec1a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384233Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#78603}
-
Jochen Eisinger authored
I'm not going to realistically work on resolving them. Change-Id: Idd59fe5758ab7132fa2412477242bc045b0ee02d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378636Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Auto-Submit: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/main@{#78602}
-
Yang Guo authored
R=leszeks@chromium.org Change-Id: I8e5930d9ed946ae12cad98b3456055aefcef7d18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386593 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78601}
-
Patrick Thier authored
This CL fixes 2 issues with string internalization when the string table is shared: 1. In-place migration of a string's map to Internalized was done before it was sure that the string is going to be internalized (outside the critical section). To fix this problem StringTableKey::AsHandle() is now split into StringTableKey::PrepareForInsertion(), which is invoked outside the critical section and creates a copy if necessary, and StringTableKey::GetHandleForInsertion(), which is invoked inside the critical section only for string table misses. Migration of the map is handled by this method. 2. TryStringToIndexOrLookupExisting() didn't handle already internalized strings. So far this was impossible, as this method was only invoked for strings that were checked not to be internalized. However with a shared string table, the string could be internalized after the checks. Bug: v8:12007 Change-Id: I193d6b54dc41360eee47d21cbcaa36d2652d85dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368103Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#78600}
-
Benedikt Meurer authored
This unifies and simplifies the way we instrument async functions for the purpose of async stack traces and async stepping. It does so while retaining the observable behavior on the inspector level (for now). Previously we'd mark the implicit promise of the async function object with the async task ID, and whenever we awaited, we'd copy the async task ID to the throwaway promise that is created by the `await`. This however made things unnecessarily interesting in the following regards: 1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the `AsyncFunctionFinished` events, coming from the throwaway promises, while the implicit promise is "done". This is especially confusing with rejection propagation and requires very complex stepping logic for async functions (after this CL it'll be possible to unify and simplify the stepping logic). 2. We have to thread through the "can suspend" information from the Parser all the way through AsyncFunctionReject/AsyncFunctionResolve to the async function instrumentation to decide whether to cancel the pending task when the async function finishes. This CL changes the instrumentation to only happen (non recurringly) for the throwaway promises allocated upon `await`. This solves both problems mentioned above, and works because upon the first `await` the stack captured for the throwaway promise will include the synchronous part as expected, while upon later `await`s the synchronous part will be empty and the asynchronous part will be the stack captured for the previous throwaway promise (and the V8Debugger automatically short circuits stacks with empty synchronous part). Bug: chromium:1280519, chromium:1277451, chromium:1246867 Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78599}
-
jiepan authored
Bug: v8:12228 Change-Id: I233efc9fc4636c25baba6a689f7038331fd1f32b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303806Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Jie Pan <jie.pan@intel.com> Cr-Commit-Position: refs/heads/main@{#78598}
-
Jakob Gruber authored
CompleteInobjectSlackTracking potentially shrinks multiple maps, and the relation between these maps should be preserved in a concurrent environment. Thus it is not enough to make each modification atomically, but all related map modifications must be within a critical section. We do this by locking the map_updater_access mutex CompleteInobjectSlackTracking, and hence moving the function to the MapUpdater class. Bug: chromium:1274445,v8:7990 Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78597}
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/fbc6faf..b9f6d0a Add Latin-ASCII transliteration (Frank Tang) https://chromium.googlesource.com/chromium/deps/icu/+/b9f6d0a R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,ftang@chromium.org Change-Id: Ic00c9e3f4aa2a14a80e33f090975c73ec1169fa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384678 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#78596}
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/0d98dba..31e7941 Add docs for `ThreadRange`. (#1318) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/31e7941 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,mlippautz@chromium.org Change-Id: Iffb9cb817ddef0cf1accdcb5327d4a4ef4dc548e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384677 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#78595}
-
Frank Tang authored
Bug: v8:11544 Change-Id: I1f8fa01ece950addac048c5ae94d8c961666f720 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384241Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/main@{#78594}
-
- 12 Jan, 2022 17 commits
-
-
Milad Fa authored
Implementations are added to macro-assembler to be shared between liftoff and code generator. Change-Id: Ibe326a80f71cad41dadbb62ebbcb9b8797f1871f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384540Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#78593}
-
Eric Seckler authored
Fixes perfetto compile. Example failure: https://ci.chromium.org/ui/p/chromium/builders/try/linux-perfetto-rel/6137/overview Change-Id: Ia74f8d339ffbf1733f334043dea19872ea8c7ee4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383778Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#78592}
-
Michael Lippautz authored
The field is updated on the main thread and read on threads using LocalHeap to possibly trigger GC in fuzzing configurations. Bug: chromium:1286699 Change-Id: I15330b7542358ce1a2307a1f258655126b252c03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383776Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78591}
-
Clemens Backes authored
The last update (using tools/wasm/update-wasm-fuzzers.sh) was in November 2020, thus update again to add modules from all existing tests to the corpus used by ClusterFuzz. This increases the number of files in the corpus from 47196 to 53779. R=ahaas@chromium.org Change-Id: Ie293bda0b4d5d7c34d5b7c53d8115d9d3883f1db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379813Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#78590}
-
Junliang Yan authored
Change-Id: I6f0a3f813f94dc350c4dd1aa257db516b973c1c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383315Reviewed-by: Milad Farazmand <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#78589}
-
Dominik Inführ authored
We might run TRACE_GC with ThreadKind::kMain not only on each isolate's main thread but also on the shared isolate's thread during a shared GC. The DCHECK is too restrictive for the latter case. This is safe because the shared GC will stop all main threads before starting its work. Bug: v8:11708 Change-Id: I1f40140d6502b1ec797dfa783fb693ed213efb3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380522Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78588}
-
gengjiawen authored
Provide a stub `third_party_heap::Heap` implementation to work around linker erors with Visual Studio. Refs: https://github.com/bnoordhuis/v8-cmake/pull/50 Bug: v8:10427 Change-Id: I435081d8cb195d1db999db699df3d3751663c81d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366367Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78587}
-
Simon Zünd authored
CDP has a "ExceptionDetails" structure that is attached to various CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate". The stack trace in the "ExceptionDetails" structure is used in various places in DevTools. The information in the "ExceptionDetails" structure is extracted from a v8::Message object. Message objects are normally created at the exception throw site and may augment the error with manually inspecting the stack (both to capture a fresh stack trace in some cases, as well as to calculate location info). The problem is that in some cases we want to get an "ExceptionDetails" structure after the fact, e.g. when logging a JS "Error" object in a catch block. This means we can't reuse Isolate::CreateMessage as the JS stack at call time is unrelated to the time when an Error object was thrown. To re-use some of the code, this CL introduces a new "CreateMessageFromException" method that is only available from the debugging interface (not public V8 API!). The new method works similar to Isolate::CreateMessage, but: 1) Does not look at the current JS stack, neither for a fresh stack trace nor for location information. 2) Only uses the "detailed" stack trace for location info. This is because the "simple" stack trace could have already been serialized by accessing Error#stack. Bug: chromium:1278650 Doc: https://bit.ly/runtime-get-exception-details Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#78586}
-
Patrick Thier authored
Strengthen the assertion in CallFunction, that only callable functions (not class constructors) are passed. Change-Id: I2dc2d061cdc9930b5b8926285f021f9772e97570 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380529Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#78585}
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I5280a22240ef5e920f701e991ed13d8b8881fc6b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377122Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#78584}
-
Dominik Inführ authored
This is a reland of 86038ecf Compared to the previous CL this one is adding a TSAN suppression for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client isolates may be locked in any order. This would be detected by TSAN as a potential race. Add some additional DCHECKs to compensate for that missing test coverage. As a cleanup this CL also removes the unused methods ContainsLocalHeap() and ContainsAnyLocalHeap() from LocalHeap. Original change's description: > [heap] Optimize time to reach global safepoint > > Initial support for global safepoints kept it simple by entering a > safepoint for each of them one after another. This means > time-to-global-safepoint is the sum of all time-to-safepoint operations. > We can improve this slightly by splitting up the safepoint iteration > into two operations: > > 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier > and sets SafepointRequested flag for all client threads) > 2) Block until all runnning client threads reach a safepoint > > We now perform operation 1) for all clients first and only then start > with operation 2). > > Bug: v8:11708 > Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78308} Bug: v8:11708, v8:12492 Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78583}
-
Thibaud Michaud authored
- Add an ActiveSuspender root, similar to the ActiveContinuation root. - Add the missing "parent" field to the Suspender, which points to the outer Suspender when they are nested, and update that field when entering a new Suspender. - Add the missing "state" field and update it when the state of the Suspender changes. R=ahaas@chromium.org CC=fgm@chromium.org Bug: v8:12191 Change-Id: I7a95f44f81390a347c6ef252ec6184fb4f0b0455 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345003Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#78582}
-
Nikolaos Papaspyrou authored
This CL contains minor refactorings to some parts of the garbage collector: - Space iterators. - Removes a redundant call to Heap::CreateFillerObjectAt. - Heap::CompleteSweepingFull now ensures that sweeping in the C++ managed heap is also completed. - Checks, comments and code cleanup. Change-Id: I14a7fe45c270c463c94c86f45b0e65757249d548 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377125Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Cr-Commit-Position: refs/heads/main@{#78581}
-
Dominik Inführ authored
This CL doesn't change behavior, only refactors MemoryAllocator: * De-templatify class, MemoryAllocator is used on slow path and doesn't really need templates for performance. * Rename FreeMode names * Move methods into private section of class Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78580}
-
Igor Sheludko authored
The Isolate might not be aware that remapped builtins are used (see Code::OffHeapInstructionStart()), so always try to lookup PC in the remapped builtins if they are available. Bug: chromium:1241665, v8:11460 Change-Id: Iefc373cf0ea0110c8c002b7677e6a1fd8fd45319 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379817Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78579}
-
Nikolaos Papaspyrou authored
Change-Id: I8e2b0756ac2cbbb3275a9560cfab749a9009033b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3365265Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Cr-Commit-Position: refs/heads/main@{#78578}
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: Ieedb5bb0d6555cdf6c628f6700f7116ca142a2d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3376963Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#78577}
-