Issue 12689 in v8: Increase CodeRange size under external code space + sharing pointer compression cage

[s… via monorail]

Status: Assigned
Owner: s...@chromium.org
CC: kbab...@chromium.org, ish...@chromium.org
Components: Runtime
Priority: 1
Type: FeatureRequest

New issue 12689 by s...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689

The maximum virtual memory reservation for CodeRange is controlled by kMaximalCodeRangeSize, which on x64 desktop is 128MB.

Historically this size pre-dates the shared process-wide pointer compression cage. With sharing of the process-wide pointer compression cage, the CodeRange was also made process-wide, so this size feels much more constraining than before. However, carving out more of the 4GB pointer compression reservation also seemed undesirable.

Most recently, the code space was moved out of the pointer compression cage entirely in v8:11880, making it easier to increase kMaximalCodeRangeSize.

cc kbabbit, who reported the Microsoft Office are hitting OOMs in code space due to the 128MB size.

ishell@, WDYT? What's a reasonable max size here?

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[sligh… via monorail]

Updates:
Cc: sligh...@chromium.org

Comment #1 on issue 12689 by sligh...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c1

(No comment was entered for this change.)

[s… via monorail]

Comment #2 on issue 12689 by s...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c2

Adding more context from offline discussion with ishell@. The 128MB limit currently is due to M1 Macs, which can encode a max of 128MB in pc-relative (i.e. "near") jumps. While it is unproblematic to increase the limit on x64, we can't do so without major performance regressions on M1.

[kbabb… via monorail]

Updates:
Cc: -kbab...@chromium.org kbabb...@microsoft.com

Comment #3 on issue 12689 by kbabb...@microsoft.com: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c3

(No comment was entered for this change.)

[s… via monorail]

Updates:
Owner: ----

Comment #4 on issue 12689 by s...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c4

[s… via monorail]

Updates:
Status: Available

Comment #5 on issue 12689 by s...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c5

[ish… via monorail]

Updates:
NextAction: 2022-04-01

Comment #6 on issue 12689 by ish...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c6

Setting NextAction date to the point when we might have more info about workarounds for performance regressions on M1 mentioned in #c2.

[s… via monorail]

Comment #8 on issue 12689 by s...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c8

Igor, any updates here?

[lpard… via monorail]

Updates:
Cc: lpard...@microsoft.com
Labels: msft-consider

Comment #9 on issue 12689 by lpard...@microsoft.com: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c9

We performed some experiments increasing the Maximal Code Range Size to 512MB in x86_64 architectures. Our data showed a decrease in Edge renderer crashes by 3-5%. Is there any reason to not bump this value up on x86_64 at least as a temporary mitigation for OOM crashes?

[verwa… via monorail]

Updates:
Owner: ish...@chromium.org
Status: Assigned

Comment #10 on issue 12689 by verw...@google.com: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c10

We're also hitting this often: we often crash while trying to set up new isolates for workers. Increasing code range size makes sense to me.

[ish… via monorail]

Comment #11 on issue 12689 by ish...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c11

I'll increase the code range on x64 in the next days and work on arm64 around next week.

[Git Watcher via monorail]

Comment #12 on issue 12689 by Git Watcher: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c12

The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/911412803a954f2adb6e82d36e1245bc8ae2a138

commit 911412803a954f2adb6e82d36e1245bc8ae2a138
Author: Igor Sheludko <ish...@chromium.org>
Date: Tue May 17 13:17:23 2022

[ext-code-space][x64] Increase max code range size to 512 MB

... when external code space is enabled.

Bug: v8:11880, v8:12689
Change-Id: I0efa09a27d636df3d36d2da13ac26c7f2fedb94c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650744
Reviewed-by: Toon Verwaest <verw...@chromium.org>
Commit-Queue: Igor Sheludko <ish...@chromium.org>
Auto-Submit: Igor Sheludko <ish...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80594}

[modify] https://crrev.com/911412803a954f2adb6e82d36e1245bc8ae2a138/src/common/globals.h

[ish… via monorail]

Comment #13 on issue 12689 by ish...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c13

Issue chromium:1325001 has been merged into this issue.

[Git Watcher via monorail]

Comment #14 on issue 12689 by Git Watcher: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c14

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/3ba66cd26a1eda249c93c637c7aa6b40adf8dec3

commit 3ba66cd26a1eda249c93c637c7aa6b40adf8dec3
Author: Igor Sheludko <ish...@chromium.org>
Date: Wed May 25 19:01:04 2022

[ext-code-space][arm64] Increase max code range size to 256Mb

... when external code space is enabled.

Since we are using near jump/call instruction only for [tail]calling
builtins, we can increase the code range as long as we can guarantee
that the remapped builtins are always reachable. We can do that by
remapping embedded builtins into the middle of the code range.

Bug: v8:11880, v8:12689

Change-Id: I69901634586df3c35618ea7bd5311102e4675f6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669107
Reviewed-by: Dominik Inführ <dinf...@chromium.org>
Commit-Queue: Igor Sheludko <ish...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80810}

[modify] https://crrev.com/3ba66cd26a1eda249c93c637c7aa6b40adf8dec3/src/heap/code-range.cc
[modify] https://crrev.com/3ba66cd26a1eda249c93c637c7aa6b40adf8dec3/src/common/globals.h

[lpard… via monorail]

Comment #15 on issue 12689 by lpard...@microsoft.com: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c15

After the change in #c14 we have been hitting a CHECK in mksnapshot when trying to crosscompile for win-arm64 in x86_64 windows machines. Our temporary mitigation was to turn the max code range size back to 128 Mb for win-arm64. Could you share any insights on why this could be happening? The crash is reproducible most of the time, but sometimes mksnapshot runs successfully. This is the call stack

# Check failed: padded_reservation.InVM(address, params.reservation_size).
#
#
#
#FailureMessage Object: 0000001B69ECA470
==== C stack trace ===============================

v8::base::debug::StackTrace::StackTrace [0x00007FF70F9501EB+27] (o:\v8\src\base\debug\stack_trace_win.cc:173)
v8::platform::`anonymous namespace'::PrintStackTrace [0x00007FF70F8ECD37+39] (o:\v8\src\libplatform\default-platform.cc:29)
V8_Fatal [0x00007FF70F8E570D+221] (o:\v8\src\base\logging.cc:166)
v8::internal::VirtualMemoryCage::InitReservation [0x00007FF70ECF3E1C+1084] (o:\v8\src\utils\allocation.cc:375)
v8::internal::CodeRange::InitReservation [0x00007FF70E87D2F9+281] (o:\v8\src\heap\code-range.cc:140)
v8::internal::CodeRange::EnsureProcessWideCodeRange [0x00007FF70E87D7D0+432] (o:\v8\src\heap\code-range.cc:310)
v8::internal::Heap::SetUp [0x00007FF70E8CA2C7+183] (o:\v8\src\heap\heap.cc:5712)
v8::internal::Isolate::Init [0x00007FF70E85A9ED+1789] (o:\v8\src\execution\isolate.cc:4043)
v8::internal::Isolate::InitWithoutSnapshot [0x00007FF70E85A2E6+22] (o:\v8\src\execution\isolate.cc:3850)
v8::SnapshotCreator::SnapshotCreator [0x00007FF70E6C9ED0+208] (o:\v8\src\api\api.cc:492)
v8::internal::CreateSnapshotDataBlobInternal [0x00007FF70ECDFB23+83] (o:\v8\src\snapshot\snapshot.cc:747)
main [0x00007FF70E6C455B+2011] (o:\v8\src\snapshot\mksnapshot.cc:294)

[ish… via monorail]

Updates:
Labels: Priority-3

Comment #16 on issue 12689 by ish...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c16

Re #c15, the issue should have been fixed by https://chromium-review.googlesource.com/c/v8/v8/+/3695382.

Keeping the issue open in case we'd like to support 512Mb code ranges with short builtin calls for arm64.

[ish… via monorail]

Comment #17 on issue 12689 by ish...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c17

Issue 13151 has been merged into this issue.

[ish… via monorail]

Comment #18 on issue 12689 by ish...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c18

Issue 13179 has been merged into this issue.

[Git Watcher via monorail]

Comment #19 on issue 12689 by Git Watcher: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c19

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/3dab0e7156e8ae60e33818b5a780e4f69c4a29c1

commit 3dab0e7156e8ae60e33818b5a780e4f69c4a29c1
Author: ish...@chromium.org <ish...@chromium.org>
Date: Tue Aug 23 12:18:34 2022

[cleanup] Move various xxx_BOOL macros from flag-definitions.h

... to globals.h. The latter is included into flags.h and thus
the flag-defnitions.h can rely on those values to be defined.
The xxx_BOOL macros that were used in #if expressions in
flag-definitions.h are now explicitly checked for being defined.

This change allows using the constants also in the globals.h header.

Bug: v8:12689
Change-Id: I2498502284ab1e8dc8a3526229613ea1ce6624bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3849377
Commit-Queue: Leszek Swirski <les...@chromium.org>

Commit-Queue: Igor Sheludko <ish...@chromium.org>
Auto-Submit: Igor Sheludko <ish...@chromium.org>

Reviewed-by: Leszek Swirski <les...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82662}

[modify] https://crrev.com/3dab0e7156e8ae60e33818b5a780e4f69c4a29c1/src/flags/flag-definitions.h
[modify] https://crrev.com/3dab0e7156e8ae60e33818b5a780e4f69c4a29c1/src/common/globals.h

[Git Watcher via monorail]

Comment #20 on issue 12689 by Git Watcher: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c20

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/3094a923922aeeb1e4e847256d3929b6a361bc05

commit 3094a923922aeeb1e4e847256d3929b6a361bc05
Author: ish...@chromium.org <ish...@chromium.org>
Date: Tue Aug 23 13:18:26 2022

[x64][arm64] Increase max code range size for full ptr builds

Sparkplug generates a lot of code and the default limit of 128 MB also
hurts non-pointer compression builds which is used by Node.js.

This CL keeps the old limit only for pointer compression configurations
without external code space because in this case the code range is
allocated in the pointer compression cage and thus bigger code range
steals the address space from the regular V8 heap.

Bug: v8:12689
Change-Id: I3c68daf6cd5322d7e30249a054a7c6d6e38fb8c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3850291
Auto-Submit: Igor Sheludko <ish...@chromium.org>
Reviewed-by: Michael Lippautz <mlip...@chromium.org>
Commit-Queue: Michael Lippautz <mlip...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82666}

[modify] https://crrev.com/3094a923922aeeb1e4e847256d3929b6a361bc05/src/common/globals.h

[ecmzi… via monorail]

Updates:
Cc: ah...@chromium.org

Comment #21 on issue 12689 by ecmzi...@chromium.org: Increase CodeRange size under external code space + sharing pointer compression cage
https://bugs.chromium.org/p/v8/issues/detail?id=12689#c21

Adobe also seems to run into the same problem if multiple tabs are opened and the JS glue code required for Wasm adds up. For Windows, the limit is at about 3-4 tabs until we crash with an OOM.

Is there any suggestion how to mitigate that issue?