Weak Ref Processing

[Roman Kennke]

>> because precleaning takes care of them
> 
> The precleaning running in the concurrent cycle (Traversal Mode) takes in
> our case significant portion of the concurrent cycle. Not sure,
> 
> but the source code indicates to me that the precleaning is done with 1
> worker only (not using all ConcGCThreads threads available).
> 
> Something to be improved?

yes, maybe. we're looking into it. It's possible that the relevant code 
is not actually multithread-safe. Not sure what the reason was to make 
it 1-threaded.

>> Enqueueuing (putting references on associated ReferenceQueue, if any), is
> done in final-mark STW pause as well.
> 
> Enqueueuing 150k weak references has already significant impact to the
> final-mark STW pause in our case. It can easily jump from 5ms to 30ms range
> 
> just because of the enqueueuing need. We are even considering to create an
> application solution for 'slowly' clearing strong references to split
> 
> enqueueuing over several cycles.

Yeah. Concurrent reference processing would solve that because it moves 
the enqueueing into the subsequent concurrent phase. I know how to do 
that in Shenandoah, I 'only' need to get around to it (just like all the 
other dozen or so loose ends ;-) ).

Cheers,
Roman