RFR: Shenandoah String Dedup refactoring

[Zhengyu Gu]

Hi Roman,

On 06/02/2018 04:39 AM, Roman Kennke wrote:
> 
> Is that a thread-local variable ?:
> 
> +  static __thread uint _worker_id;
Yes, borrowed from ZGC :-(

> 
> 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?

Yes, it can be stuffed there. But is it a better place? where the 
work_id only applies to worker thread?

Thanks,

-Zhengyu


> 
> 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
>>>
> 
>