Directions on fixing JDK-8297285

[Ashutosh Mehra]

Hi,

I am trying to find a way to fix JDK-8297285: Shenandoah pacing causes
assertion failure during VM initialization.

The scenario is during VM init if the main thread exhausts the allocation
budget, then the shenandoah pacer would cause it to wait. The call to wait
can hit assertion self->is_active_Java_thread() in Monitor::wait() as the
main thread is not yet added to the thread list, and therefore
is_active_Java_thread() returns false.

The approach I have in mind is to delay initialization of ShenandoahPacer
until the main thread is considered an active Java thread. But there is no
hook to capture that event in the GC. The closest I found is
`CollectedHeap::post_initialize()`. The comments for
`CollectedHeap::post_initialize()` indicate this *may* be the right place
to initialize the ShenandoahPacer:

```
  // In many heaps, there will be a need to perform some initialization
activities
  // after the Universe is fully formed, but before general heap allocation
is allowed.
  // This is the correct place to place such initialization methods.
  virtual void post_initialize();
```

However, there are still some VM init activities between the call to
CollectedHeap::post_initialize() in universe_post_init and the call to
Threads::add(main_thread) in Threads::create_vm(). So initializing in
CollectedHeap::post_initialize() can still break if enough heap allocations
happen during those activities.
I am wondering if there is a better place to initialize the
ShenandoahPacer, or another approach to fix this situation.
Here is the current set of changes [0] that initialize ShenandoahPacer in
CollectedHeap::post_initialize().

[0]
https://github.com/openjdk/jdk/compare/master...ashu-mehra:jdk:JDK-8297285

Thanks,
Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20221121/c53c3d4e/attachment-0001.htm>