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