RFR: 8189276: Make SuspendibleThreadSet and related code available to other GCs
David Holmes
david.holmes at oracle.com
Thu Oct 19 01:51:13 UTC 2017
On 19/10/2017 6:35 AM, Kim Barrett wrote:
>> On Oct 17, 2017, at 5:10 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>
>>
>>> The SuspendibleThreadSet API for synchronizing any non-Java thread with safepoints currently resides under gc/g1. It is very useful for other GCs too (in particular, Shenandoah does use it too), so I wanted to move it to a common location like gc/common. Then Kim Barrett commented that it might actually be useful for other threads outside GC land and to put it under runtime/. So I did:
>>>
>>> http://cr.openjdk.java.net/~rkennke/8189276/webrev.00/
>>>
>>> I also added a generic hook to call the STS from safepoint sync/desync, which is consequently used by G1 now. In other words, the CollectedHeap API that Erik Ö introduced is no longer used by G1. Only CMS still uses that API because it has its own way to sync with safepoints. I filed another bug for this. Although I have my doubt it will ever be fixed. This seems to have been very carefully evolved (to put it positive), and the risk of breaking it is relatively high, and thus doesn't seem worth the struggle to make it fit the STS.
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8189276
>>>
>>> What do you think? Ok to go in?
>>>
>> Replying to myself here.
>> I must admit that I am a bit reluctant to expose it to runtime/ unless there's a specific need for it. So maybe go back to the original plan to move it into gc/common and leave all the rest alone for now? What do others think?
>>
>> Roman
>
> My reasoning for suggesting it belongs in runtime is that I think it
> is a part of the API for SafepointSynchronize. The fact that it was
> backed in via GC (and in a really ugly way, initially) doesn't change
> my opinion about that. But since runtime folks all seem to be saying
> "nope, never heard of it, don't need it for anything non-GC, don't
> want any responsibility for it", I guess keeping it a GC thing is what
> we'll do. But I still think it's strange that SafepointSynchronize is
> calling into GC code. (With the CMS mechanism being its own
> additional oddity.)
I also find it strange, but this is GC code so ... if GC is doing
something strange that requires the safepoint code to coordinate with it
then we can oblige. That doesn't mean we want to own all that crazy GC
code! ;-)
Cheers,
David
>
>
More information about the hotspot-runtime-dev
mailing list