RFR(M): Shenandoah string dedup support

[Roman Kennke]

>
>> + // Shenandoah needs (special-1) rank of the lock, because write
>> barrier can evaculate objects while
>>
>> s/evaculate/evacuate/
>>
>> I assume you have thought hard about the locking stuff? No way to
>> avoid it?
>>
> I know this is ugly, but I don't see how to work around the scenario
> described in comments. Any suggestions?
>
Not at this point.
>> - } else if (UseG1GC || (UseShenandoahGC &&
>> ShenandoahSuspendibleWorkers)) {
>> + } else if (UseG1GC || (UseShenandoahGC &&
>> (ShenandoahSuspendibleWorkers || UseStringDeduplication))) {      
>> SuspendibleThreadSet::synchronize();
>>
>> Can you explain why we need to suspend/resume GC threads at
>> safepoints when using string dedup?
>
> We need to suspend g1StringDedupThread, anyway to do so without
> suspending GC threads?
If (! ShenandoahSuspendibleWorkers), we never register any GC thread to
the suspendible thread sets, i.e. the string dedup thread would be the
only one. Which means we're probably ok? Can you check this?

If yes, then please push!

Roman