JVM crash G1 garbage collector

[kaaphi]

Describe the bug

We are experiencing occasional JVM crashes in one of our services. We are running 6 instances of this service, and we've see one or two crashes about once a day or once every other day.

Possibly the same as #184

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (g1VMOperations.cpp:119), pid=8, tid=75
# guarantee(target_pause_time_ms > 0.0) failed: target_pause_time_ms = 0.000000 should be positive
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.12.7.1 (17.0.12+7) (build 17.0.12+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.12.7.1 (17.0.12+7-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x71c608] VM_G1CollectForAllocation::VM_G1CollectForAllocation(unsigned long, unsigned int, GCCause::Cause, double)+0x80
#
# Core dump will be written. Default location: Core dumps may be processed with ""/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h"" (or dumping to /app/core.8)
#
# JFR recording file will be written. Location: /app/hs_err_pid8.jfr
#
# An error report file with more information is saved as:
# /app/hs_err_pid8.log
#
# If you would like to submit a bug report, please visit:
# https://github.com/corretto/corretto-17/issues/

To Reproduce

Not reproducible on demand.

Expected behavior

No crashes.

Platform information

OS: Amazon Linux release 2 (using the amazoncorretto:17 docker image)
Version Corretto-17.0.12.7.1 (17.0.12+7) (build 17.0.12+7-LTS)

Additional context

In all the examples we've looked at, the crash has happened while uploading a directory to S3.

For VM crashes, please attach the error report file. By default the file name is hs_err_pidpid.log, where pid is the process ID of the process.
hs_err_pid8_example1.log
hs_err_pid8_example2.log
hs_err_pid8_example3.log

[Autumn808]

Were looking into this thank you.

[kaaphi]

Is there anything else we can provide here to help out?

[lutkerd]

We are still looking at the issue internally and there is nothing obvious in the hs_err or code and no upstream issue for this either.