8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context by sspitsyn · Pull Request #8878 · openjdk/jdk

sspitsyn · 2022-05-25T07:23:36Z

A part of this issue was contributed with the following changeset:

commit ea23e73
Author: Daniel D. Daugherty <dcubed@openjdk.org>
Date: Mon Nov 8 14:45:04 2021 +0000

8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
Reviewed-by: coleenp, sspitsyn, dholmes, rehn

The following change in src/hotspot/share/runtime/thread.cpp added new assert:

bool JavaThread::java_suspend() {
- ThreadsListHandle tlh;
- if (!tlh.includes(this)) {
- log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
- return false;
- }
+ guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
 + "missing ThreadsListHandle in calling context.");
  return this->handshake_state()->suspend();
}

This new assert misses a check for target thread as being current JavaThread.

Also, the JVMTI SuspendThread is protected with TLH:

JvmtiEnv::SuspendThread(jthread thread) {
  JavaThread* current = JavaThread::current();
  ThreadsListHandle tlh(current);              <= TLS defined here!!!

   oop thread_oop = NULL;
   {
     JvmtiVTMSTransitionDisabler disabler(true);

However, it is possible that a new carrier thread (and an associated JavaThread) can be created after the TLH was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created JavaThread which is unprotected by the TLH.
The right way to be protected from this situation it is to prevent mount state transitions with JvmtiVTMSTransitionDisabler before the TLH is set as in the change below:

@@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
 jvmtiError
 JvmtiEnv::SuspendThread(jthread thread) {
   JavaThread* current = JavaThread::current();
-  ThreadsListHandle tlh(current);

   jvmtiError err;
   JavaThread* java_thread = NULL;
   oop thread_oop = NULL;
   {
     JvmtiVTMSTransitionDisabler disabler(true);
+    ThreadsListHandle tlh(current);

     err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
     if (err != JVMTI_ERROR_NONE) {

This problem exist in all JVMTI Suspend functions:
SuspendThread, SuspendThreadList and SuspendAllVirtualThreads.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context

Reviewers

David Holmes (@dholmes-ora - Reviewer)
Patricio Chilano Mateo (@pchilano - Reviewer)
Alex Menkov (@alexmenkov - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/8878/head:pull/8878
$ git checkout pull/8878

Update a local copy of the PR:
$ git checkout pull/8878
$ git pull https://git.openjdk.java.net/jdk pull/8878/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 8878

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/8878.diff

…ssing ThreadsListHandle in calling context

bridgekeeper · 2022-05-25T07:24:35Z

👋 Welcome back sspitsyn! 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 · 2022-05-25T07:27:25Z

@sspitsyn The following labels will be automatically applied to this pull request:

hotspot
serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-05-25T07:31:11Z

Webrevs

00: Full (f894c659)

dholmes-ora

These changes look good to me - as per our discussion in JBS issue.

Thanks,
David

openjdk · 2022-05-25T11:49:06Z

@sspitsyn This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context

Reviewed-by: dholmes, pchilanomate, amenkov

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 21 new commits pushed to the master branch:

3d6d7b7: 8287338: tools/javac/api/snippets/TestJavaxToolsSnippets.java failing tier1 on all platforms
7156f98: 8279513: jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after 8278795
f786e2a: 8284037: Snippet-files subdirectory not automatically detected when in unnamed package
c674348: 8263075: C2: simplify anti-dependence check in PhaseCFG::implicit_null_check()
0b3d409: 8261768: SelfDestructTimer should accept seconds
bc0379e: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver
0b8dd4a: 8284966: Update SourceVersion.RELEASE_19 description for language changes
e990fec: 8287089: G1CollectedHeap::is_in_cset() can be const methods
81d7eaf: 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers
796494d: 8284944: assert(cnt++ < 40) failed: infinite cycle in loop optimization
... and 11 more: https://git.openjdk.java.net/jdk/compare/a0cccb54791d954bf08da5aac9b9794e370617c8...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

dholmes-ora · 2022-05-25T11:52:40Z

One query though - don't we have a self-suspension test that would have triggered the guarantee failure? If we don't then we should (obviously the resume will be a bit racy).

sspitsyn · 2022-05-25T16:30:29Z

The test serviceability/jvmti/vthread/SelfSuspendDisablerTest is triggering this guarantee.
But it needs this update in the SuspendThread in order to do it.

#  Internal Error (/scratch/sspitsyn/loom5/open/src/hotspot/share/runtime/thread.cpp:1781), pid=31157, tid=31182
#  guarantee(Thread::is_JavaThread_protected_by_TLH( this)) failed: missing ThreadsListHandle in calling context.
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-05-19-0744187.sspitsyn...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-05-19-0744187.sspitsyn..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1a41724]  JavaThread::java_suspend()+0xa4
. . . . .
---------------  S U M M A R Y ------------

Command Line: -Dtest.vm.opts=-XX:+CreateCoredumpOnCrash --enable-preview -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:-VerifyContinuations -XX:+CheckUnhandledOops -Xcheck:jni -Dmain.wrapper=Virtual -Dtest.tool.vm.opts=-J-XX:+CreateCoredumpOnCrash -J--enable-preview -J-Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -J-XX:-VerifyContinuations -J-XX:+CheckUnhandledOops -J-Xcheck:jni -J-Dmain.wrapper=Virtual -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/jdk -Dcompile.jdk=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/jdk -Dtest.timeout.factor=1.0 -Dtest.nativepath=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/test/hotspot/jtreg/native -Dtest.root=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg -Dtest.name=serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java -Dtest.file=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java -Dtest.src=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest -Dtest.src.path=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest:/scratch/sspitsyn/loom5/open/test/lib -Dtest.classes=/scratch/sspitsyn/tst/loom5/JTwork/classes/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d -Dtest.class.path=/scratch/sspitsyn/tst/loom5/JTwork/classes/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d:/scratch/sspitsyn/tst/loom5/JTwork/classes/test/lib -XX:+CreateCoredumpOnCrash --enable-preview -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:-VerifyContinuations -XX:+CheckUnhandledOops -Xcheck:jni -Dmain.wrapper=Virtual -Djava.library.path=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/test/hotspot/jtreg/native --enable-preview -agentlib:SelfSuspendDisablerTest com.sun.javatest.regtest.agent.MainWrapper /scratch/sspitsyn/tst/loom5/JTwork/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d/main.1.jta

Host: hotspot-oraclelinux-01, Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz, 32 cores, 235G, Oracle Linux Server release 7.8
Time: Wed May 25 16:23:30 2022 GMT elapsed time: 0.322123 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x00007f3440022920):  JavaThread "Thread-1" [_thread_in_vm, id=31182, stack(0x00007f348afee000,0x00007f348b0ef000)]

Stack: [0x00007f348afee000,0x00007f348b0ef000],  sp=0x00007f348b0ed620,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1a41724]  JavaThread::java_suspend()+0xa4
V  [libjvm.so+0x1315989]  JvmtiEnvBase::suspend_thread(oop, JavaThread*, bool, int*)+0x379
V  [libjvm.so+0x12fba6a]  JvmtiEnv::SuspendThread(_jobject*)+0x1ba
V  [libjvm.so+0x12a42df]  jvmti_SuspendThread+0x17f
C  [libSelfSuspendDisablerTest.so+0x21a8]  Java_SelfSuspendDisablerTest_selfSuspend+0x38
j  SelfSuspendDisablerTest.selfSuspend()V+0
j  SelfSuspendDisablerTest.lambda$main$0()V+0
j  SelfSuspendDisablerTest$$Lambda$1+0x0000000801001200.run()V+0
j  java.lang.Thread.run()V+13 java.base@19-internal
v  ~StubRoutines::call_stub 0x00007f34f6db9d47
V  [libjvm.so+0xfba465]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505
V  [libjvm.so+0xfbacf4]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
V  [libjvm.so+0xfbb167]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
V  [libjvm.so+0x113d20b]  thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.so+0x1a40b7a]  JavaThread::thread_main_inner()+0x21a
V  [libjvm.so+0x1a4e430]  Thread::call_run()+0x100
V  [libjvm.so+0x16fc2b4]  thread_native_entry(Thread*)+0x104

sspitsyn · 2022-05-25T16:31:28Z

David, thank you for review and help with analysis of this problem!

pchilano

LGTM.

sspitsyn · 2022-05-25T21:07:27Z

Thank you for quick review, Patricio!

sspitsyn · 2022-05-26T00:27:49Z

Thank you for review, Alex!

sspitsyn · 2022-05-26T00:27:58Z

/integrate

openjdk · 2022-05-26T00:29:39Z

Going to push as commit 94811c0.
Since your change was applied there have been 21 commits pushed to the master branch:

3d6d7b7: 8287338: tools/javac/api/snippets/TestJavaxToolsSnippets.java failing tier1 on all platforms
7156f98: 8279513: jdk/javadoc/doclet/testDocletExample/TestDocletExample.java fails after 8278795
f786e2a: 8284037: Snippet-files subdirectory not automatically detected when in unnamed package
c674348: 8263075: C2: simplify anti-dependence check in PhaseCFG::implicit_null_check()
0b3d409: 8261768: SelfDestructTimer should accept seconds
bc0379e: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver
0b8dd4a: 8284966: Update SourceVersion.RELEASE_19 description for language changes
e990fec: 8287089: G1CollectedHeap::is_in_cset() can be const methods
81d7eaf: 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers
796494d: 8284944: assert(cnt++ < 40) failed: infinite cycle in loop optimization
... and 11 more: https://git.openjdk.java.net/jdk/compare/a0cccb54791d954bf08da5aac9b9794e370617c8...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-05-26T00:29:54Z

@sspitsyn Pushed as commit 94811c0.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

dholmes-ora · 2022-05-26T02:32:47Z

I was expecting there to be an existing non-vthread-related test for self-suspension. That seems to be a hole in our test coverage.

sspitsyn · 2022-05-26T06:58:26Z

This nsk.jvmti test is also failing with the guarantee for current platform thread:
test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002

#  Internal Error (/scratch/sspitsyn/loom5/open/src/hotspot/share/runtime/thread.cpp:1781), pid=7458, tid=7506
#  guarantee(Thread::is_JavaThread_protected_by_TLH( this)) failed: missing ThreadsListHandle in calling context.
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-05-19-0744187.sspitsyn...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-05-19-0744187.sspitsyn..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1a41814]  JavaThread::java_suspend()+0xa4
. . . . . . . . . . . . . . . .
---------------  T H R E A D  ---------------

Current thread (0x000014b91001d0f0):  JavaThread "Thread-1" [_thread_in_vm, id=7506, stack(0x000014b92bafa000,0x000014b92bbfb000)]

Stack: [0x000014b92bafa000,0x000014b92bbfb000],  sp=0x000014b92bbf8ef0,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1a41814]  JavaThread::java_suspend()+0xa4
V  [libjvm.so+0x1315a79]  JvmtiEnvBase::suspend_thread(oop, JavaThread*, bool, int*)+0x379
V  [libjvm.so+0x12fb9ca]  JvmtiEnv::SuspendThread(_jobject*)+0x1ba
V  [libjvm.so+0x12a42df]  jvmti_SuspendThread+0x17f
C  [libhs202t002.so+0xc0a7]  callbackMethodExit.part.0+0x107
V  [libjvm.so+0x1336887]  JvmtiExport::post_method_exit_inner(JavaThread*, methodHandle&, JvmtiThreadState*, bool, frame, jvalue&) [clone .part.0]+0x307
V  [libjvm.so+0x133ac71]  JvmtiExport::notice_unwind_due_to_exception(JavaThread*, Method*, unsigned char*, oop, bool)+0x531
V  [libjvm.so+0xfad21a]  InterpreterRuntime::exception_handler_for_exception(JavaThread*, oopDesc*)+0xb9a
j  nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.display()V+19
j  nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.playWithThis()V+1
j  nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.run()V+1
v  ~StubRoutines::call_stub 0x000014b98fa09d47
V  [libjvm.so+0xfba465]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505
V  [libjvm.so+0xfbacf4]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
V  [libjvm.so+0xfbb167]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
V  [libjvm.so+0x113d20b]  thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.so+0x1a40c6a]  JavaThread::thread_main_inner()+0x21a
V  [libjvm.so+0x1a4e520]  Thread::call_run()+0x100
V  [libjvm.so+0x16fc3a4]  thread_native_entry(Thread*)+0x104

Full list of nsk.jvmti tests that fail by this root cause:

vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002
vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001
vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002
vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003
vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003
vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004
vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003

To make it clear, these tests did not fail without my fix because the TLH was protecting current thread being suspended. My fix made current thread unprotected by the TLH in SuspendThread, SuspendThreadList and SuspendAllVirtualThreads as we discussed with you in JBS.

dholmes-ora · 2022-05-26T07:42:20Z

Ah I see. Hmmm it might be argued (when Dan gets back) that the TLH was in fact intended/expected to cover the current thread - even though the current thread never needs such protection.

sspitsyn · 2022-05-27T12:21:54Z

Requiring protection of current thread with TLH makes it ugly for cases of self suspend as a nested extra TLH is required to protect current thread. The issue with self suspends is that having a jvmtiVTMSTransitionDisabler in its context is not allowed as it would cause deadlocks.
Not requiring TLH for protection of current thread makes TLH congruent with jvmtiVTMSTransitionDisabler.

dcubed-ojdk · 2022-06-01T18:59:38Z

Before Loom, there was a TLH in the outer JVM/TI SuspendThread() entry point
so the current thread was already protected. Here's the relevant code from
build/macosx-x86_64-normal-server-release/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp
in JDK18:

static jvmtiError JNICALL
jvmti_SuspendThread(jvmtiEnv* env,
            jthread thread) {

#if !INCLUDE_JVMTI 
  return JVMTI_ERROR_NOT_AVAILABLE; 
#else 
  if(!JvmtiEnv::is_vm_live()) {
    return JVMTI_ERROR_WRONG_PHASE;
  }
  Thread* this_thread = Thread::current_or_null(); 
  if (this_thread == NULL || !this_thread->is_Java_thread()) {
    return JVMTI_ERROR_UNATTACHED_THREAD;
  }
  JavaThread* current_thread = JavaThread::cast(this_thread);
  MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, current_thread));
  ThreadInVMfromNative __tiv(current_thread);
  VM_ENTRY_BASE(jvmtiError, jvmti_SuspendThread , current_thread)
  debug_only(VMNativeEntryWrapper __vew;)
  PreserveExceptionMark __em(this_thread);
  JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env);
  if (!jvmti_env->is_valid()) {
    return JVMTI_ERROR_INVALID_ENVIRONMENT;
  }

  if (jvmti_env->get_capabilities()->can_suspend == 0) {
    return JVMTI_ERROR_MUST_POSSESS_CAPABILITY;
  }
  jvmtiError err;
  JavaThread* java_thread = NULL;
  ThreadsListHandle tlh(this_thread);
  if (thread == NULL) {
    java_thread = current_thread;
  } else {
    err = JvmtiExport::cv_external_thread_to_JavaThread(tlh.list(), thread, &java_thread, NULL);
    if (err != JVMTI_ERROR_NONE) {
      return err;
    }
  }
  err = jvmti_env->SuspendThread(java_thread);
  return err;
#endif // INCLUDE_JVMTI
}

so it was definitely my intent that the current thread be protected
by the TLH that was in the entry code. Yes, that protection is not
needed, but that's the way I implemented it when
is_JavaThread_protected_by_TLH() was added to the system.

sspitsyn · 2022-06-08T20:16:59Z

Yes, I understand it. Thank you for clarification!

8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: mi…

f894c65

…ssing ThreadsListHandle in calling context

openjdk bot added the rfr Pull request is ready for review label May 25, 2022

openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels May 25, 2022

dholmes-ora approved these changes May 25, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 25, 2022

pchilano approved these changes May 25, 2022

View reviewed changes

alexmenkov approved these changes May 25, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label May 26, 2022

openjdk bot closed this May 26, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 26, 2022

sspitsyn deleted the br7 branch May 26, 2022 00:33

Conversation

sspitsyn commented May 25, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented May 25, 2022

Uh oh!

openjdk bot commented May 25, 2022

Uh oh!

mlbridge bot commented May 25, 2022

Webrevs

Uh oh!

dholmes-ora left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented May 25, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dholmes-ora commented May 25, 2022

Uh oh!

sspitsyn commented May 25, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sspitsyn commented May 25, 2022

Uh oh!

pchilano left a comment

Choose a reason for hiding this comment

Uh oh!

sspitsyn commented May 25, 2022

Uh oh!

sspitsyn commented May 26, 2022

Uh oh!

sspitsyn commented May 26, 2022

Uh oh!

openjdk bot commented May 26, 2022

Uh oh!

openjdk bot commented May 26, 2022

Uh oh!

dholmes-ora commented May 26, 2022

Uh oh!

sspitsyn commented May 26, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dholmes-ora commented May 26, 2022

Uh oh!

sspitsyn commented May 27, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcubed-ojdk commented Jun 1, 2022

Uh oh!

sspitsyn commented Jun 8, 2022

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

sspitsyn commented May 25, 2022 •

edited by openjdk bot

Loading

openjdk bot commented May 25, 2022 •

edited

Loading

sspitsyn commented May 25, 2022 •

edited

Loading

sspitsyn commented May 26, 2022 •

edited

Loading

sspitsyn commented May 27, 2022 •

edited

Loading