RFR: Shenandoah String Dedup refactoring

[Roman Kennke]

Is that a thread-local variable ?:

+  static __thread uint _worker_id;

Is there no better way to achieve the same? E.g. we don't want to put it
into ShenandoahThreadLocalData or such? The worker_id seems small enough
to actually fit into a byte. Maybe we have a byte-field left in ShTLD
without requiring to blow up its word-size?

Other than that, looks good.

Thank you!!
Roman

> Shenandoah only webrev:
> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/sh-only/webrev.00/
> 
> 
> Thanks,
> 
> -Zhengyu
> 
> On 05/29/2018 03:54 PM, Zhengyu Gu wrote:
>> Hi,
>>
>> This refactoring is based on upstream JDK-8203641, which is still
>> under review
>> (http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032565.html).
>>
>>
>> We initially borrowed G1's string deduplication implementation, but we
>> diverged at one point, due to we may need to enqueue candidates inside
>> write barrier. It is not the case anymore.
>>
>> Once JDK-8203641 upstreamed, we can share dedup table and thread
>> implementation, only need to plugin in our queue implementation.
>>
>> It looks like StringDedupTable is another candidate to be replaced by
>> ConcurrentHashTable, we should be able to benefit from it too.
>>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/webrev.00/
>>
>>
>>
>> Test:
>>    hotspot_gc_shenandoah (fastdebug and release)
>>
>> Thanks,
>>
>> -Zhengyu
>>