FastSyncRoots and monitor deflation question

[Roman Kennke]

> Also...:
> 
>> I also see this stuff:
>>
>>   experimental(bool, ShenandoahMergeSafepointCleanup, false,
>>    \
>>               "Do safepoint cleanup piggy-backed on thread scans")
>>    \
>>
>>    \
>>   experimental(uint, ParallelSafepointCleanupThreads, 0,
>>    \
>>           "Number of parallel threads used for safepoint cleanup")
>>    \
>>
>>    \
>>
>>
>> I.e. our improvements (if they are) to safepoint cleanup are turned off
>> by default, and thus probably totally untested. Do we know if it
>> actually helps? Would it be worth turning on by default so that it gets
>> testing? Otherwise remove/revert the corresponding code changes and
>> wait/work-on concurrent monitor deflation?
> 
> ParallelSafepointCleanupThreads is something that is basically
> upstreamed, at least the API, and used by other collectors (G1 and Z).
> We may just want to enable it.
> 
> About piggy-backing SP cleanup, I dunno if it's useful. It seems mostly
> untested though, and also introduces some significant upstreaming burden
> in very hairy code (synchronizer...). Maybe remove that stuff and wait
> for conc monitor deflation?

And sure enough, this stuff crashes when enabled
(+ShenandoahMergeSafepointCleanup). Not sure if it ever worked stable.

I also posted a note on hotspot-runtime-dev and hotspot-gc-dev to see if
there is interest in getting something like this upstreamed:

http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-September/023259.html

If not, I suggest to drop that stuff.

Roman