8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report #4006

dholmes-ora · 2021-05-13T02:14:43Z

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report

Reviewers

Thomas Stuefe (@tstuefe - Reviewer) ⚠️ Review applies to 147b5cf
Kevin Walls (@kevinjwalls - Committer) ⚠️ Review applies to 147b5cf
Gerard Ziemski (@gerard-ziemski - Committer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4006

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

Using diff file

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

…or should not contain suggestion to submit a bug report

bridgekeeper · 2021-05-13T02:14:50Z

👋 Welcome back dholmes! 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 · 2021-05-13T02:16:21Z

@dholmes-ora The following label will be automatically applied to this pull request:

hotspot

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

dholmes-ora · 2021-05-13T02:17:26Z

/label remove hotspot
/label add hotspot-runtime

openjdk · 2021-05-13T02:17:43Z

@dholmes-ora
The hotspot label was successfully removed.

openjdk · 2021-05-13T02:18:58Z

@dholmes-ora
The hotspot-runtime label was successfully added.

mlbridge · 2021-05-13T03:54:10Z

Webrevs

tstuefe

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp

src/hotspot/share/utilities/debug.hpp

tstuefe

All good.

openjdk · 2021-05-13T10:49:23Z

@dholmes-ora 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:

8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report

Reviewed-by: stuefe, kevinw, gziemski

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 87 new commits pushed to the master branch:

cf97252: 8264561: javap get NegativeArraySizeException on bad instruction
b8856b1: 8263614: javac allows local variables to be accessed from a static context
ea36836: 8267236: Versioned platform link in TestMemberSummary.java
d5a15f7: 8263438: Unused method AbstractMemberWriter.isInherited
dd5a84c: 8267162: Add jtreg test group definitions for langtools
39a454b: 8260331: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "ERROR: icon and imageIcon not same."
a29612e: 8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException
a555fd8: 8264734: Some SA classes could use better hashCode() implementation
2313a21: 8266637: CHT: Add insert_and_get method
7b736ec: 8266489: Enable G1 to use large pages on Windows when region size is larger than 2m
... and 77 more: https://git.openjdk.java.net/jdk/compare/18e9d28e8af02650ba30e4816404df48b1062162...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.

kevinjwalls · 2021-05-14T10:14:09Z

Hi David, looks good.

I get it now I've found that should_report_bug() really means "is vm internal error". Literally, "is this NOT a native memory allocation failure".

If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.)

tstuefe · 2021-05-14T11:20:43Z

Hi Kevin,

If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.)

My preference would be to keep the patches as concise as possible, because that makes backporting patches easier. vmError is overdue for some cleanups, but I'd prefer those concentrated in a cleanup RFE, which would give us just one commit to packport, instead of spreading cleanups over unrelated patches.

Just my 5c, David may see this differently.

Cheers, Thomas

mlbridge · 2021-05-14T18:34:31Z

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
298: const char* detail_fmt, va_list detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Thanks,
David

mlbridge · 2021-05-14T18:34:38Z

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
298: const char* detail_fmt, va_list detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Thanks,
David

mlbridge · 2021-05-14T18:34:42Z

Mailing list message from Thomas Stüfe on hotspot-runtime-dev:

Hi David,

On Thu, May 13, 2021 at 10:04 AM David Holmes <david.holmes at oracle.com>
wrote:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org>
wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate
we've requested a Java OOM error to be fatal. A new overload of
report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that
encompasses more than just printing the bug submission URL, so I added a
new specific check for that.

Checked hs_err files before and after with the fix, from the
CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have
attempted to so so multiple times, but the patches ballooned. I may try
again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib
marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
298: const char* detail_fmt, va_list
detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

This enum, signal numbers (posix) and windows SEH codes are mashed together
in VMError::_id. I guess this is some effort to make sure value ranges for
these three semantically different things don't intersect.

I don't like this design though. I would like to keep these as two separate
things: at the highest lvl, differentiate between internal fatal errors and
crashes. For each type keep detail info: For crashes,
signal number+context+siginfo. For asserts, error type and maybe context.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char*
detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int
line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Yes, but atm the sole user of this api lives in debug.cpp. Otherwise this
API is only exposed via the specialized report_java_out_of_memory().

Never mind though, it is not that important.

Thanks,
David

Patch looks good to me.

Cheers, Thomas

mlbridge · 2021-05-14T18:34:48Z

Mailing list message from Thomas Stüfe on hotspot-runtime-dev:

Hi David,

On Thu, May 13, 2021 at 10:04 AM David Holmes <david.holmes at oracle.com>
wrote:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org>
wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate
we've requested a Java OOM error to be fatal. A new overload of
report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that
encompasses more than just printing the bug submission URL, so I added a
new specific check for that.

Checked hs_err files before and after with the fix, from the
CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have
attempted to so so multiple times, but the patches ballooned. I may try
again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib
marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
298: const char* detail_fmt, va_list
detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

This enum, signal numbers (posix) and windows SEH codes are mashed together
in VMError::_id. I guess this is some effort to make sure value ranges for
these three semantically different things don't intersect.

I don't like this design though. I would like to keep these as two separate
things: at the highest lvl, differentiate between internal fatal errors and
crashes. For each type keep detail info: For crashes,
signal number+context+siginfo. For asserts, error type and maybe context.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char*
detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int
line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Yes, but atm the sole user of this api lives in debug.cpp. Otherwise this
API is only exposed via the specialized report_java_out_of_memory().

Never mind though, it is not that important.

Thanks,
David

Patch looks good to me.

Cheers, Thomas

gerard-ziemski · 2021-05-14T18:56:48Z

src/hotspot/share/utilities/debug.cpp

+void report_fatal(const char* file, int line, const char* detail_fmt, ...) {
+  va_list detail_args;
+  va_start(detail_args, detail_fmt);
+  report_fatal_impl(INTERNAL_ERROR, file, line, detail_fmt, detail_args);
+  va_end(detail_args);
+}


Do we really need this API? Can't we just update:

#define fatal(...) \ do { \ TOUCH_ASSERT_POISON; \ report_fatal(INTERNAL_ERROR, __FILE__, __LINE__, __VA_ARGS__); \ BREAKPOINT; \ } while (0)

As the fatal() macro seems to be the only user of the existing report_fatal then yes I think we can simplify this as you suggest. I had thought it was used directly from elsewhere.

Thanks for the suggestion.

mlbridge · 2021-05-17T02:19:15Z

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Kevin,

Thanks for looking at this.

On 14/05/2021 8:18 pm, Kevin Walls wrote:

On Thu, 13 May 2021 08:06:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

Review comments from Thomas

Marked as reviewed by kevinw (Committer).

Hi David, looks good.

I get it now I've found that should_report_bug() really means "is vm internal error". Literally, "is this NOT a native memory allocation failure".

If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.)

I couldn't determine exactly what "should_report_error" was really
trying to distinguish, beyond the obvious case of "report the bug submit
URL". As Thomas notes there is potential for more rework in this area,
but I don't want to increase the scope of the current change.

Thanks,
David

tstuefe · 2021-05-17T05:41:59Z

Looks still good.

..Thomas

mlbridge · 2021-05-17T06:57:13Z

Mailing list message from David Holmes on hotspot-runtime-dev:

Thanks Thomas!

David

On 17/05/2021 3:44 pm, Thomas Stuefe wrote:

gerard-ziemski

Looks good, thanks!

dholmes-ora · 2021-05-17T22:37:47Z

Thanks Gerard!

dholmes-ora · 2021-05-17T22:37:56Z

/integrate

openjdk · 2021-05-17T22:39:33Z

@dholmes-ora Since your change was applied there have been 92 commits pushed to the master branch:

2effdd1: 8267112: JVMCI compiler modules should be kept upgradable
da4dfde: 8264777: Overload optimized FileInputStream::readAllBytes
3b11d81: 8266742: Check W^X state on possible safepoint
79b3944: 8266520: Revert to OpenGL as the default 2D rendering pipeline for macOS
3c010a7: 8265705: aarch64: KlassDecodeMovk mode broken
cf97252: 8264561: javap get NegativeArraySizeException on bad instruction
b8856b1: 8263614: javac allows local variables to be accessed from a static context
ea36836: 8267236: Versioned platform link in TestMemberSummary.java
d5a15f7: 8263438: Unused method AbstractMemberWriter.isInherited
dd5a84c: 8267162: Add jtreg test group definitions for langtools
... and 82 more: https://git.openjdk.java.net/jdk/compare/18e9d28e8af02650ba30e4816404df48b1062162...master

Your commit was automatically rebased without conflicts.

Pushed as commit cd1c17c.

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

8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryErr…

f83eda4

…or should not contain suggestion to submit a bug report

openjdk bot added the hotspot hotspot-dev@openjdk.org label May 13, 2021

openjdk bot removed the hotspot hotspot-dev@openjdk.org label May 13, 2021

openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label May 13, 2021

dholmes-ora marked this pull request as ready for review May 13, 2021 03:48

openjdk bot added the rfr Pull request is ready for review label May 13, 2021

tstuefe suggested changes May 13, 2021

View reviewed changes

src/hotspot/share/utilities/debug.cpp Outdated Show resolved Hide resolved

src/hotspot/share/utilities/debug.cpp Outdated Show resolved Hide resolved

src/hotspot/share/utilities/debug.hpp Outdated Show resolved Hide resolved

src/hotspot/share/utilities/debug.hpp Show resolved Hide resolved

Review comments from Thomas

147b5cf

tstuefe approved these changes May 13, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 13, 2021

kevinjwalls approved these changes May 14, 2021

View reviewed changes

gerard-ziemski suggested changes May 14, 2021

View reviewed changes

Simplify API changes based on Gerard's suggestion.

8ff1935

gerard-ziemski approved these changes May 17, 2021

View reviewed changes

openjdk bot closed this May 17, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 17, 2021

dholmes-ora deleted the 8266404 branch May 17, 2021 22:54

8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report #4006

8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report #4006

Uh oh!

Conversation

dholmes-ora commented May 13, 2021 • 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 13, 2021

Uh oh!

openjdk bot commented May 13, 2021

Uh oh!

dholmes-ora commented May 13, 2021

Uh oh!

openjdk bot commented May 13, 2021

Uh oh!

openjdk bot commented May 13, 2021

Uh oh!

mlbridge bot commented May 13, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

tstuefe left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tstuefe left a comment

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

kevinjwalls commented May 14, 2021

Uh oh!

tstuefe commented May 14, 2021

Uh oh!

mlbridge bot commented May 14, 2021

Uh oh!

mlbridge bot commented May 14, 2021

Uh oh!

mlbridge bot commented May 14, 2021

Uh oh!

mlbridge bot commented May 14, 2021

Uh oh!

gerard-ziemski May 14, 2021

Choose a reason for hiding this comment

Uh oh!

dholmes-ora May 17, 2021

Choose a reason for hiding this comment

Uh oh!

mlbridge bot commented May 17, 2021

Uh oh!

tstuefe commented May 17, 2021

Uh oh!

mlbridge bot commented May 17, 2021

Uh oh!

gerard-ziemski left a comment

Choose a reason for hiding this comment

Uh oh!

dholmes-ora commented May 17, 2021

Uh oh!

dholmes-ora commented May 17, 2021

Uh oh!

openjdk bot commented May 17, 2021

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

dholmes-ora commented May 13, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented May 13, 2021 •

edited

Loading

openjdk bot commented May 13, 2021 •

edited

Loading