RFR: Parallelize safepoint cleanup

Kim Barrett kim.barrett at oracle.com
Mon May 29 12:27:15 UTC 2017


> On May 29, 2017, at 7:27 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 29/05/2017 8:47 PM, Kim Barrett wrote:
>>> On May 29, 2017, at 4:23 AM, Roman Kennke <rkennke at redhat.com> wrote:
>>> I implemented this using the following:
>>> 
>>>  if (ParallelSafepointCleanup &&
>>> FLAG_IS_DEFAULT(ParallelSafepointCleanupThreads)) {
>>>    // This will pick up ParallelGCThreads if set...
>>>    FLAG_SET_DEFAULT(ParallelSafepointCleanupThreads,
>>> Abstract_VM_Version::parallel_worker_threads());
>>>  }
>> Just following along, and not presently planning to do a real review, but the
>> above caught my eye.  Clients of the VM_Version infrastructure should never
>> directly reference Abstract_VM_Version::<anything>, as doing so may bypass
>> platform-specific specializations.
>> I thought I’d filed a bug about that sort of thing, but apparently that got pushed
>> deep onto my todo list.  I’ll go take care of that now.
> 
> Beat you to it by six years:
> 
> https://bugs.openjdk.java.net/browse/JDK-7041262
> 
> That's a pretty sad statement. Fortunately most things in Abstract_VM_Version are not overridden.
> 
> David

I was sure I’d looked for an existing bug, but obviously not!

It looks like there are some worms under that rock.  The initialize issue looks like
a case where there should be more than one stage to the initialization.  In fact,
there’s already been some work done in that direction, e.g. we now have
early_initialize() and init_before_ergo().  I’ll go add some comments to the bug.




More information about the hotspot-gc-dev mailing list