Original commit message:

    Improve V8 GC logic for external memory

    The logic for V8 GC normally only takes the external memory growth
    since last mark-compact into account. Unfortunately, the amount of
    external memory recorded at the end of MC is often too high. The
    reason is that it might take a while for the external memory
    associated with the GCed objects to be released (e.g. V8 itself post a
    task to release external memory for ArrayBuffer backing stores). In a
    worst case scenario GC is driven only by external memory and none of
    the external memory is released by the end of the MC. Then each MC
    will record the external memory at its highest point and the GC logic
    will allow the external memory to grow a bit higher each time which
    can lead to excessive memory use.

    This patch improves the situation a bit by calculating the growth from
    the lowest external memory seen since the last MC. That way the growth
    calculation will be offset from a level presumably closer to the
    intended one (to what it would have been if the external memory
    associated with the GCed objects was released during the MC). Now,
    this fix is not perfect because it can be thrown off by external
    memory growth occurring before the lingering memory is
    released. However, it seems to work rather well in practice (e.g. when
    playing MSE video on YT).

    Bug: v8:10185
    Change-Id: Ifcdd87eb45f3ae4a99d2aeec667c3ae4ca9a52b6
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042711
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66193}

Refs: v8/v8@4b1447e

Original commit message:

    [api] Add embedder-vs-V8 build configuration compatibility check

    v8::V8::Initialize() will fail with meaningful error upon build
    configuration mismatch.

    Bug: v8:10041
    Change-Id: Ic69ba68ef1764b356beef0f204fe58b45bae3c49
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144953
    Commit-Queue: Igor Sheludko <ishell@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#67116}

Refs: v8/v8@2db93c0

Original commit message:

    Make StringBuffer::string return a StringView instead of a reference.

    A StringView is pretty light, so this should be similar to
    how absl::string_view is typically used, e.g. see the guidance here:
    https://github.com/abseil/abseil-cpp/blob/master/absl/strings/string_view.h
    I suspect this reasoning holds even though StringView (defined
    just above StringBuffer in v8-inspector.h) carries an additional bool.
    This yields a small simplification of the StringBuffer implementations.

    Change-Id: I03f850049afe2327913070838f39649fcdfa6fa8
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045110
    Commit-Queue: Yang Guo <yangguo@chromium.org>
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66858}

(Neighbouring-line conflicts were resolved while backporting.)

Refs: v8/v8@844fe8f

Original commit message:

    api: Remove deprecated TracedReference::SetFinalizationCallback method

    TracedReference is supposed to be as light-weight as possible without
    destructor or other callbacks, essentially just representing a plain managed
    reference.

    Change-Id: Iae52cf7460e3623f1fb7d183757ecd39b2431369
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033173
    Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66106}

Refs: v8/v8@94723c1

Original commit message:

    [api] Remove deprecated and non-functional method

    The functionality was not used since a long time, and was hence removed
    for the 8.1 branch, and the method was deprecated.
    This CL removed the deprecated method completely.

    R=adamk@chromium.org

    Bug: v8:10155
    Change-Id: Iae299d64decb7230d38c2fda8d269a7b0387bb0d
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033169
    Reviewed-by: Adam Klein <adamk@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66167}

Refs: v8/v8@f0057af

Original commit message:

    [api] remove deprecated snapshot APIs

    R=verwaest@chromium.org

    Fixed: v8:7463
    Change-Id: I3d0127865ad0430d38124c3ad8ed3bc63ba4e6d3
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149421
    Auto-Submit: Yang Guo <yangguo@chromium.org>
    Commit-Queue: Toon Verwaest <verwaest@chromium.org>
    Reviewed-by: Toon Verwaest <verwaest@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#67169}

Refs: v8/v8@fa3e37e

Original commit message:

    [unwinder] Advance deprecation of the old unwinder API

    Chrome uses the new version now.

    Bug: v8:8116
    Change-Id: I59af8d2c6a897a852acd6de3a7938a4b8d3943e4
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110015
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66796}

Refs: v8/v8@d1253ae

Original commit message:

    [api] Remove deprecated DeserializeOrCompile method

    This method was used to implement deserialization via the value
    serializer. It was deprecated since this functionality is not used any
    more, and hence untested.
    This CL cleans up by removing the deprecated method and two private
    helper methods.

    R=adamk@chromium.org

    Bug: v8:10155
    Change-Id: I4dda1949fd4f1b499cb6f8d6e6a76b642179303a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033171
    Reviewed-by: Adam Klein <adamk@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66096}

Refs: v8/v8@e395d16

Original commit message:

    [weakrefs] Call Isolate::ClearKeptObjects() as part of microtask checkpoint

    In the spec, WeakRefs that are dereferenced are kept alive until there's
    no JS on the stack, and then the host is expected to call
    ClearKeptObjects to clear those strong references [1]. HTML calls
    ClearKeptObjects at the end of a PerformMicrotaskCheckpoint [2].

    In V8, leaving this up to the embedder is error prone in the same way
    the deprecated FinalizationGroup callback APIs were error prone: it
    depends on the embedder doing the right thing. This CL moves the call to
    ClearKeptObjects to be after running of microtasks within V8.

    However, the Isolate::ClearKeptObjects API should not be removed or
    deprecated in case an embedder uses an entirely custom MicrotaskQueue
    implementation and invokes MicrotaskQueue::PerformCheckpoint manually.

    [1] https://tc39.es/proposal-weakrefs/#sec-clear-kept-objects
    [2] whatwg/html#4571

    Bug: v8:8179
    Change-Id: Ie243804157b56241ca69ed8fad300e839a0c9f75
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055967
    Commit-Queue: Shu-yu Guo <syg@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66327}

Refs: v8/v8@9f0f2cb

Original commit message:

    Reland "[weakrefs] Schedule FinalizationGroup cleanup tasks from within V8"

    Deprecate the following explicit FinalizationGroup APIs in favor of
    automatic handling of FinalizationGroup cleanup callbacks:
      - v8::Isolate::SetHostCleanupFinalizationGroupCallback
      - v8::FinaliationGroup::Cleanup

    If no HostCleanupFinalizationGroupCallback is set, then
    FinalizationGroup cleanup callbacks are automatically scheduled by V8
    itself as non-nestable foreground tasks.

    When a Context being disposed, all FinalizationGroups that are
    associated with it are removed from the dirty list, cancelling
    scheduled cleanup.

    This is a reland of 31d8ff7ac5f4a91099f2f06f01e43e9e7aa79bc4

    Bug: v8:8179, v8:10190
    Change-Id: I704ecf48aeebac1dc2c05ea1c052f6a2560ae332
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045723
    Commit-Queue: Shu-yu Guo <syg@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66208}

Refs: v8/v8@55a01ec

Original commit message:

    [tools] Add a VMState for Atomics.wait

    We will use this state in devtools via the inspector to indicate
    whether a thread is currently stuck polling in atomics.wait.

    VMState already distinguishes the important states we care about which
    are idle vs. running JS. We also want to know the state for
    atomics.wait(), which is commonly used in WebWorkers to poll the main
    page for work to do.

    This CL just adds and maintains the state and adds assertions in
    atomics tests. Another CL will emit inspector notifications when the
    VMState changes in a way that the inspector cares about.

    Re-flow comments as a drive-by cleanup.

    Bug: chromium:1025490
    Change-Id: I961051bfb846aa20454a56214310370ea8e47d1c
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033168
    Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66071}

Refs: v8/v8@e8ba569

Original commit message:

    [api] Remove deprecated wasm module type check

    The method was deprecated in favor of {IsWasmModuleObject}.

    R=adamk@chromium.org

    Bug: v8:10155
    Change-Id: Id21a1b74dde5576c2c82cc209555c22209a9e5d4
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033170
    Reviewed-by: Adam Klein <adamk@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66469}

Refs: v8/v8@700b1b9

Original commit message:

    [api] New function for reallocating ArrayBuffer backing store

    This patch adds a new BackingStore::Reallocate function that internally
    uses a new ArrayBuffer::Allocator::Reallocate provided by the embedder.

    The default implementation of the function simply copies the backing
    store. The embedder can override the function and provide a more
    efficient implementation e.g. using realloc.

    Bug: v8:9908, v8:9380

    Change-Id: I2179c80ba199c045b6900c620a813916150e7098
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007274
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66044}

Refs: v8/v8@b5c917e

Original commit message:

    Expose the %ObjProto_valueOf% intrinsic object to embedders

    https://html.spec.whatwg.org/multipage/history.html#the-location-interface
    HTML Location platform objects need to be initialized with using
    the %ObjProto_valueOf% intrinsic object.

    This patch exposes the %ObjProto_valueOf% intrinsic object to
    embedders.

    Example usage is: https://crrev.com/c/2102306

    Change-Id: Iec58135773e01aed5de330c0c5dea89a49835a52
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102408
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66747}

Refs: v8/v8@98b1ef8

Refs: v8/v8@9e52d5c

Refs: v8/v8@6523801
Refs: v8/v8@8d08318

Refs: v8/v8@d5b444b

This brings ABI compatibility for several changes related to
the fast API calls implementation in V8.

Refs: nodejs#30786