8312182: THPs cause huge RSS due to thread start timing issue by tstuefe · Pull Request #3223 · openjdk/jdk11u-dev

tstuefe · 2026-06-05T14:47:05Z

This is a streamlined version of the fix for JDK 11 (and eventually, 8).

Thanks to @tabata-d for doing preparatory analysis and proposing a first version of backport fixes; we ended up deciding against those in favor of a simpler, streamlined solution for JDK 11 and (later) JDK 8, but his analysis was valuable and made the problem apparent to us.

The problem occurs when multiple Java threads are created, and khugepaged is scheduled between thread starts and Java stack guard page creation. Kernel minimizes VMA fragmentation, so there is a high chance that the stacks for these new threads are placed adjacent to each other. No guard pages have been established yet, so all these thread stacks look like one big memory area just ripe for THP coalescing. Of course, those THPs shatter a moment later when the Java guards are placed, but by that time the damage is done: now all pages in the new thread stacks are resident, and we have burned CPU time to make it so.

The problem is clearly that khugepaged is too aggressive.

Newer kernels have toned down khugepaged's aggressiveness: it is now a lot less likely to coalesce THPs out of sparsely populated areas like thread stacks. So the problem is non-existent in newer kernels (>=6).

It still very much exists in RHEL 7 and 8. Allegedly also in RHEL 9 (see openjdk/jdk8u-dev#746 (comment)), though I was not able to reproduce it there.

Some numbers:

RHEL 8 x64: 5000 idle threads, time between thread creation and Java guard placement artificially increased with a delay of 100ms:

THP=madvise: RSS = 0.31 GB
THP=always: RSS = 6.54 GB

Fixing this in older JVMs is very important, since those are typically deployed on older Linux versions that are much more vulnerable to this problem.

The fix is very simple: if we feel this could be a problem, we enable glibc guard pages. On older glibc variants, this narrows the "dangerous" time window significantly; on newer glibc variants it avoids the problem completely (glibc got smarter, too).

The most vulnerable architectures are those with small THP sizes:

x64 (THP size 2MB)
aarch64 with 4K pages (THP size 1MB)
s390 (THP size 1MB)

Note, though, that for s390, IBM/Red Hat strongly recommends switching off THPs, as they do not play well with Z's internal memory manager.

The following architectures are less affected because the THP size is large. Bloated RSS is still possible, but one needs a fair bit of bad luck, or an application with exceptionally large stack sizes:

ppc64: 16MB THP size
aarch64 with 16K pages: 16MB THP size

The fix is unclean. In newer releases, the fix was implemented on top of a number of code improvements. I avoided pulling all of that stuff into JDK 11 and instead rewrote parts of the patch.

Notable changes to the upstream version:

In os_linux.cpp, I provided a small inline variant of the "are we thp-always mode" function that in newer versions lives in the new hugepage detection code in hugepages.cpp.
In os_linux.cpp, I left out a part of the original patch in os::create_thread() (// In addition to the glibc guard page ...) - that part deals with a rare corner case (e.g. 1GB large page size) and is not important enough to downport.
In THPsInThreadStackPreventionTest.java, I also provided an in-line version of the "are we thp-always mode" for test purposes instead of pulling the new HugePages helper Java framework into JDK 11.

I also integrated two small follow-ups into this patch:

8312585: Rename DisableTHPStackMitigation flag to THPStackMitigation
(https://bugs.openjdk.org/browse/JDK-8312585)
8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores
(https://bugs.openjdk.org/browse/JDK-8314139)

since these would be needed anyway.

Testing:

Tested on RHEL 8 and 9. With the fix, on RHEL 8, RSS in my example program goes down from 6.54 GB to 0.36GB.

I tested the new regression test on RHEL 8 and RHEL 9.

GHAs are fine apart from an unrelated infra problem on mac aarch64.

Hotspot tier1 and 2 tests on Fyre are running.

Risk:

With the patch, we now allocate glibc guards on the stack. So there is a theoretical increase of virtual size (VSS) by one system page (4K or 16K or 64K depending on platform) per thread. But no RSS increase: guard pages are not resident, so they don't count toward RSS.

In practice, I found the effect to be too small to measure on 4K-paged x64, even with 5000 threads (which would cause a 20KB increase in VSS). It went lost in normal random VSS fluctuations.

Theoretically, on larger-paged architectures like ppc64, the increase could cause the JVM to run against an ulimit -v limit set by an administrator. I just mentioned the risk for completeness sake. It is extremely unlikely given that java VSS is gargantuan and somewhat unpredictable, so those few KB more are lost in the random noise.

/issue 8312182
/issue 8312585
/issue 8314139

I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
JDK-8314139 needs maintainer approval
JDK-8310687 needs maintainer approval
Change must not contain extraneous whitespace
Commit message must refer to an issue
JDK-8312585 needs maintainer approval
JDK-8312182 needs maintainer approval

Issues

JDK-8312182: THPs cause huge RSS due to thread start timing issue (Bug - P3)
JDK-8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores (Bug - P4)
JDK-8310687: JDK-8303215 is incomplete (Bug - P4)
JDK-8312585: Rename DisableTHPStackMitigation flag to THPStackMitigation (Enhancement - P4)

Reviewers

Daishi Tabata (@tabata-d - no project role) 🔄 Re-review required (review applies to e113c5aa)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk11u-dev.git pull/3223/head:pull/3223
$ git checkout pull/3223

Update a local copy of the PR:
$ git checkout pull/3223
$ git pull https://git.openjdk.org/jdk11u-dev.git pull/3223/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3223

View PR using the GUI difftool:
$ git pr show -t 3223

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk11u-dev/pull/3223.diff

Using Webrev

Link to Webrev Comment

…uld fail on machine with large number of cores Reviewed-by: shade, stuefe (cherry picked from commit 733250288325bc663afc0376342d4c5a7a471cbd)

bridgekeeper · 2026-06-05T14:48:23Z

👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2026-06-05T14:50:25Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2026-06-05T14:51:09Z

@tstuefe The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

openjdk · 2026-06-05T14:51:49Z

@tstuefe
Adding additional issue to issue list: 8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores.

openjdk · 2026-06-06T05:16:29Z

@tstuefe
Updating description of additional solved issue: 8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores.

tabata-d · 2026-06-08T02:06:57Z

@tstuefe Thank you for working on the patch.

Here are the details of the reproduction I observed on RHEL 9:

OS: RHEL 9.6
Kernel: 5.14.0
glibc: 2.34
Architecture: x64
Machine cores: 4 cores

khugepaged settings:

$ find /sys/kernel/mm/transparent_hugepage/khugepaged/ -type f | while read f; do echo "$f"; cat
"$f"; done
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag
1
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared
256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs
10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan
4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap
64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs
60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed
69
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans
1

Reproducer program:
Test.java

Test.java prints /proc/self/status at runtime.

When I ran Test.java in the above environment, I got the following result:

$ ./jdk-11.0.31+11/bin/java -Xss2m -XX:+AlwaysPreTouch Test
Process PID: 100323

--- /proc/self/status ---
VmSize: 28563792 kB
VmRSS:  13053880 kB
Threads:        10020
-------------------------

After changing the THP configuration from always to madvise, I got the following result:

$ ./jdk-11.0.31+11/bin/java -Xss2m -XX:+AlwaysPreTouch Test
Process PID: 12219

--- /proc/self/status ---
VmSize: 28566808 kB
VmRSS:    693716 kB
Threads:        10020
-------------------------

On my RHEL 9 environment, I observed a significant difference in RSS depending on the THP configuration.

mlbridge · 2026-06-15T12:53:57Z

Webrevs

tstuefe · 2026-06-15T12:54:59Z

MacOS GHA errors obviously unrelated.

tstuefe · 2026-06-15T13:25:56Z

Here are the details of the reproduction I observed on RHEL 9:

OS: RHEL 9.6 Kernel: 5.14.0 glibc: 2.34 Architecture: x64 Machine cores: 4 cores

...

On my RHEL 9 environment, I observed a significant difference in RSS depending on the THP configuration.

Hmm, it could be that the kernel version delta between 9.6 and 9.8 (what I use) could be the explanation for why I did not observe the issue on RHEL 9.8. In any case, it makes sense to fix this in JDK 11 and 8.

gnu-andrew · 2026-06-15T21:27:12Z

If you change the PR title to Backport e6b87a7116dffd6f065589edd2821f182b265fa6 it should pick it up as a backport. You then only need to add the two follow-on issues via /issue.

gnu-andrew

This mostly looks good and I much prefer this to introducing a bunch of additional infrastructure just for this change.

Just a few questions:

The 17u version makes the stack_size += os::vm_page_size(); added by 8303215 conditional on the mitigation being on but I don't see that in this patch. Is that deliberate?
The 17u version turns the mitigation off when we are not in always mode using FLAG_SET_ERGO(DisableTHPStackMitigation, true); while it's a simple assignment (THPStackMitigation = false`) in this version. Again, I just wondered why the change.

A few of the switch renaming changes (8312585) crept into the first commit but this was minor enough to not cause any issue when reviewing and it'll all be squashed together for the final commit anyway. Similarly, I wondered where the test changes were until I saw them in the third commit :)

tstuefe · 2026-06-16T10:48:59Z

/issue 8312585

openjdk · 2026-06-16T10:49:27Z

This backport pull request has now been updated with issues from the original commit.

openjdk · 2026-06-16T10:50:32Z

@tstuefe
Adding additional issue to issue list: 8312585: Rename DisableTHPStackMitigation flag to THPStackMitigation.

tstuefe · 2026-06-16T10:55:02Z

Thanks @gnu-andrew for the review. Answers inline.

This mostly looks good and I much prefer this to introducing a bunch of additional infrastructure just for this change.

Just a few questions:

1. The [17u version](https://github.com/openjdk/jdk17u/commit/e6b87a7116dffd6f065589edd2821f182b265fa6#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR885) makes the `stack_size += os::vm_page_size();` added by [8303215](https://github.com/openjdk/jdk11u/commit/ff759fc8fd815d193758fc0f4702a831266a8c11) conditional on the mitigation being on but I don't see that in this patch.  Is that deliberate?

It was deliberate, and I reconsidered. It does not matter much either way. This was just to test the effectiveness of THP stack mitigation by switching it off completely, including the intra-stack-related fixes done previously by 8303215.

Since it does no harm, I took over the condition and the newer comment (mostly to not confuse future code readers who assume the patch has been integrated). I kept the old logic inside the condition, though, with an added comment for JDK 11 and 8 explaining the difference.

2. The 17u version turns the mitigation off when we are not in always mode using `FLAG_SET_ERGO`(DisableTHPStackMitigation, true);` while it's a simple assignment (`THPStackMitigation = false`) in this version.  Again, I just wondered why the change.

My bad, I thought we don't have FLAG_SET_ERGO in jdk 11. I fixed it.

A few of the switch renaming changes (8312585) crept into the first commit, but this was minor enough not to cause any issue when reviewing and it'll all be squashed together for the final commit anyway. Similarly, I wondered where the test changes were until I saw them in the third commit :)

Sorry :-)

I tested the new changes in RHEL 8 and 9, patch is still good (with me still being unable to reproduce much of the problem on RHEL 9, but I trust @tabata-d here, he wrote the bug also occurs there.)

The MacOS / Windows GHA errors are annoying but unrelated since this patch only changes linux-specific code.

tabata-d · 2026-06-16T11:08:36Z

@tstuefe Thank you for creating the patch.
I'd like to check if the issue I reproduced on RHEL 9 has been resolved. I apologize, but I can't work on it today, so I will report the results by tomorrow.

tabata-d

Using a build with this fix applied, I measured RSS in the same way in #3223 (comment). I confirmed that I do not see any abnormal RSS increasing on my REHL 9.6 environment.

The fix looks good to me overrall. I've left a few minor comments for your consideration.

tabata-d · 2026-06-16T09:03:44Z

  size_t guard_size = os::Linux::default_guard_size(thr_type);
  // Configure glibc guard page. Must happen before calling


A line break is needed here to align with upstream.

Sure, but lets only fix things the patch touches.

For backports, I believe that even a single space or line break should be aligned with upstream as much as possible. Is there any reason not to do so here?

Because this suggested linebreak was not part of the original patch and was not part of any hunks touched by it. When backporting, we try to avoid changes to code parts unrelated to the original patch.

If that is necessary/a useful goal, then a separate RFE should be done that does that (as in: "8u: align whitespace usage to upstream". And then, you'd have to trickle such a patch down the JDK versions first.

I might be missing something, but it looks like the linebreak is included in the upstream patch.
openjdk/jdk@84b325b#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR918
Could you please confirm whether this understanding is correct?

Hmm, you are right; I missed that. Okay then, I'll add the line break.

Yes, I did spot that too but it didn't seem worth mentioning as HotSpot code is already pretty divergent between releases anyway, so it's unlikely patches apply cleanly. It actually worries me a little if they do. Had it been a JDK file that changes little, it would have been more of an issue.

Still, good to see it fixed.

Co-authored-by: Daishi Tabata <tabata.daishi@fujitsu.com>

tstuefe · 2026-06-17T07:15:38Z

Thanks for testing and review, @tabata-d . I applied most of your suggestions.

gnu-andrew · 2026-06-19T00:02:28Z

Thanks @gnu-andrew for the review. Answers inline.
This mostly looks good and I much prefer this to introducing a bunch of additional infrastructure just for this change.
Just a few questions:
1. The [17u version](https://github.com/openjdk/jdk17u/commit/e6b87a7116dffd6f065589edd2821f182b265fa6#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR885) makes the `stack_size += os::vm_page_size();` added by [8303215](https://github.com/openjdk/jdk11u/commit/ff759fc8fd815d193758fc0f4702a831266a8c11) conditional on the mitigation being on but I don't see that in this patch.  Is that deliberate?
It was deliberate, and I reconsidered. It does not matter much either way. This was just to test the effectiveness of THP stack mitigation by switching it off completely, including the intra-stack-related fixes done previously by 8303215.

Since it does no harm, I took over the condition and the newer comment (mostly to not confuse future code readers who assume the patch has been integrated). I kept the old logic inside the condition, though, with an added comment for JDK 11 and 8 explaining the difference.

I agree it doesn't make a big difference as it is code that is already in 11u. Still, nice to now have it in sync with later versions.

2. The 17u version turns the mitigation off when we are not in always mode using `FLAG_SET_ERGO`(DisableTHPStackMitigation, true);` while it's a simple assignment (`THPStackMitigation = false`) in this version.  Again, I just wondered why the change.

My bad, I thought we don't have FLAG_SET_ERGO in jdk 11. I fixed it.

Yeah, my first thought was that it must not be in 11 and then I found it was :) Thanks for fixing.

A few of the switch renaming changes (8312585) crept into the first commit, but this was minor enough not to cause any issue when reviewing and it'll all be squashed together for the final commit anyway. Similarly, I wondered where the test changes were until I saw them in the third commit :)

Sorry :-)

No harm done. I just thought it worth mentioning for future backports that may be more complex.

I tested the new changes in RHEL 8 and 9, patch is still good (with me still being unable to reproduce much of the problem on RHEL 9, but I trust @tabata-d here, he wrote the bug also occurs there.)

Great. Changes look good to me so I think this is ready to go in.

The MacOS / Windows GHA errors are annoying but unrelated since this patch only changes linux-specific code.

I agree. Windows build should already be fixed by Severin's recent backport, so a merge would likely fix that one, but isn't needed with it only touching Linux code.

gnu-andrew

Current version looks good to me. I'll let @jerboaa handle approval as a final thumbs up.

openjdk · 2026-06-19T00:04:57Z

⚠️ @tstuefe This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

tabata-d

Thank you for addressing even my minor comments. Looks good to me.
I'm not a reviewer, so this doesn't have any procedual significance, but I will approve current changes anyway.

tstuefe · 2026-06-19T04:10:35Z

Thank you for addressing even my minor comments. Looks good to me. I'm not a reviewer, so this doesn't have any procedual significance, but I will approve current changes anyway.

Thank you! We always take insightful reviews from non-reviewers into account.

jerboaa · 2026-06-19T08:29:10Z

@tstuefe

Please merge master to get rid of the Windows build failures in GHA. Also this Linux x64 failure seems related:

/home/runner/work/jdk11u-dev/jdk11u-dev/test/hotspot/jtreg/runtime/os/THPsInThreadStackPreventionTest.java:93: error: cannot find symbol
            System.out.println("Failed to read " + file);
                                                   ^
  symbol:   variable file
  location: class THPsInThreadStackPreventionTest
1 error

https://github.com/tstuefe/jdk11u-dev/actions/runs/27748064701/job/82094979103#step:11:3014

Please fix. Thanks!

gnu-andrew · 2026-06-19T18:39:49Z

@tstuefe

Please merge master to get rid of the Windows build failures in GHA. Also this Linux x64 failure seems related:
/home/runner/work/jdk11u-dev/jdk11u-dev/test/hotspot/jtreg/runtime/os/THPsInThreadStackPreventionTest.java:93: error: cannot find symbol
            System.out.println("Failed to read " + file);
                                                   ^
  symbol:   variable file
  location: class THPsInThreadStackPreventionTest
1 error
https://github.com/tstuefe/jdk11u-dev/actions/runs/27748064701/job/82094979103#step:11:3014

Please fix. Thanks!

This is a regression caused by one of the last minute fixes; there is no file defined.

Defining String file = "/sys/kernel/mm/transparent_hugepage/enabled" and using file as the argument to FileReader should fix it, and also make the try line a bit shorter while we're at it.

tstuefe · 2026-06-22T12:41:17Z

Fixed and re-tested. Sorry for the trouble. Always be wary of last-minute changes :-/

gnu-andrew

I still think it would be better to add in a file variable to avoid the filename duplication and long lines as I suggested.

tstuefe · 2026-06-22T18:06:52Z

I still think it would be better to add in a file variable to avoid the filename duplication and long lines as I suggested.

Oh, I missed your suggestion. Sure, will do it tomorrow.

gnu-andrew · 2026-06-22T18:09:33Z

I still think it would be better to add in a file variable to avoid the filename duplication and long lines as I suggested.

Oh, I missed your suggestion. Sure, will do it tomorrow.

Thanks. Just bugs me a bit to see such a long path repeated. :)

jerboaa · 2026-06-23T08:44:01Z

Please merge master branch. It gets rid of the Windows build failures in GHA. Thanks!

tstuefe · 2026-06-26T07:49:29Z

I think this is good now. GHA checks were clean apart from an unrelated issue on MacOS/x86 which cannot have been caused by this PR.

I will resync master periodically until there is time to review and approve it. @gnu-andrew @jerboaa if you want to wait until the July CPU is done this is okay, too. I would like to see this fixed soon, but OTOH the bug is decades old now, so it also could wait until the October release.

jerboaa · 2026-06-26T09:44:47Z

@tstuefe Was closing the PR intentional?

gnu-andrew · 2026-06-27T01:08:15Z

I think this is good now. GHA checks were clean apart from an unrelated issue on MacOS/x86 which cannot have been caused by this PR.

I will resync master periodically until there is time to review and approve it.

I thought we already had reviewed it? Other than the file change which looks fine.

@gnu-andrew @jerboaa if you want to wait until the July CPU is done this is okay, too. I would like to see this fixed soon, but OTOH the bug is decades old now, so it also could wait until the October release.

July is already in rampdown so any changes to 11u-dev now would be for October anyway.

tstuefe · 2026-06-27T04:52:35Z

@tstuefe Was closing the PR intentional?

Oops. The heat gets to my head. Definitely not.

tstuefe added 3 commits June 5, 2026 11:48

start

b7dd921

switch rename

b317aba

8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java co…

5331ee5

…uld fail on machine with large number of cores Reviewed-by: shade, stuefe (cherry picked from commit 733250288325bc663afc0376342d4c5a7a471cbd)

openjdk Bot changed the title ~~Backport tstuefe 84b325b8 master~~ 8312585: Rename DisableTHPStackMitigation flag to THPStackMitigation Jun 5, 2026

tstuefe changed the title ~~8312585: Rename DisableTHPStackMitigation flag to THPStackMitigation~~ 8312182: THPs cause huge RSS due to thread start timing issue Jun 6, 2026

tstuefe marked this pull request as ready for review June 15, 2026 12:47

openjdk Bot added the rfr Pull request is ready for review label Jun 15, 2026

gnu-andrew reviewed Jun 15, 2026

View reviewed changes

Andrew Feedback

c8ad18a

tstuefe changed the title ~~8312182: THPs cause huge RSS due to thread start timing issue~~ Backport e6b87a7116dffd6f065589edd2821f182b265fa6 Jun 16, 2026

openjdk Bot changed the title ~~Backport e6b87a7116dffd6f065589edd2821f182b265fa6~~ 8312182: THPs cause huge RSS due to thread start timing issue Jun 16, 2026

openjdk Bot added the backport Port of a pull request already in a different code base label Jun 16, 2026

tabata-d reviewed Jun 17, 2026

View reviewed changes

tstuefe and others added 2 commits June 17, 2026 09:10

Apply suggestion from @tabata-d

efc65ff

Co-authored-by: Daishi Tabata <tabata.daishi@fujitsu.com>

Apply suggestions from code review

ebc1773

Co-authored-by: Daishi Tabata <tabata.daishi@fujitsu.com>

Add missing linebreak

e113c5a

gnu-andrew approved these changes Jun 19, 2026

View reviewed changes

tabata-d approved these changes Jun 19, 2026

View reviewed changes

Fix typo in THPsInThreadStackPreventionTest.java

e45a09a

gnu-andrew suggested changes Jun 22, 2026

View reviewed changes

common file variable

8355907

tstuefe added 2 commits June 23, 2026 15:55

Merge branch 'openjdk:master' into backport-tstuefe-84b325b8-master

ea88930

Merge branch 'openjdk:master' into backport-tstuefe-84b325b8-master

10a65fe

tstuefe closed this Jun 26, 2026

tstuefe reopened this Jun 27, 2026

		size_t guard_size = os::Linux::default_guard_size(thr_type);
		// Configure glibc guard page. Must happen before calling

Uh oh!

Conversation

tstuefe commented Jun 5, 2026 • edited by openjdk Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issues

Reviewers

Reviewing

Uh oh!

bridgekeeper Bot commented Jun 5, 2026

Uh oh!

openjdk Bot commented Jun 5, 2026

Uh oh!

openjdk Bot commented Jun 5, 2026

Uh oh!

openjdk Bot commented Jun 5, 2026

Uh oh!

openjdk Bot commented Jun 6, 2026

Uh oh!

tabata-d commented Jun 8, 2026

Uh oh!

mlbridge Bot commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

tstuefe commented Jun 15, 2026

Uh oh!

tstuefe commented Jun 15, 2026

Uh oh!

gnu-andrew commented Jun 15, 2026

Uh oh!

gnu-andrew left a comment

Choose a reason for hiding this comment

Uh oh!

tstuefe commented Jun 16, 2026

Uh oh!

openjdk Bot commented Jun 16, 2026

Uh oh!

openjdk Bot commented Jun 16, 2026

Uh oh!

tstuefe commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tabata-d commented Jun 16, 2026

Uh oh!

tabata-d left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tabata-d Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

tstuefe Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

tabata-d Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

tstuefe Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

tabata-d Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

tstuefe Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

gnu-andrew Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tstuefe commented Jun 17, 2026

Uh oh!

gnu-andrew commented Jun 19, 2026

Uh oh!

gnu-andrew left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk Bot commented Jun 19, 2026

Uh oh!

tstuefe commented Jun 5, 2026 •

edited by openjdk Bot

Loading

mlbridge Bot commented Jun 15, 2026 •

edited

Loading

tstuefe commented Jun 16, 2026 •

edited

Loading

jerboaa commented Jun 19, 2026 •

edited

Loading

tstuefe commented Jun 26, 2026 •

edited

Loading