RFR: String deduplication for traversal GC

Roman Kennke rkennke at redhat.com
Tue Jan 30 20:08:37 UTC 2018


Less clutter/boilerplate code? ;-) I guess it's mostly a matter oft taste..

Am 30. Januar 2018 21:07:20 MEZ schrieb Zhengyu Gu <zgu at redhat.com>:
>
>
>On 01/30/2018 02:48 PM, Roman Kennke wrote:
>> Am 30.01.2018 um 20:46 schrieb Roman Kennke:
>>> Am 30.01.2018 um 20:40 schrieb Zhengyu Gu:
>>>> Please review the implementation of string deduplication for 
>>>> traversal GC.
>>>>
>>>>
>>>> Webrev: 
>>>>
>http://cr.openjdk.java.net/~zgu/shenandoah/traversal_dedup/webrev.00/
>>>>
>>>>
>>>> Test:
>>>>
>>>>    hotspot_gc_shenandoah (fastdebug + release)
>>>>    specJVM with -XX:+UseStringDeduplication (fastdebug)
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>
>>> I wonder if it should be possible to make the closure templated 
>>> instead of making multiple explicit classes, like this:
>>>
>>> template <bool STRDEDUP>
>>> class ShenandoahTraversalSuperClosure .. {
>>>
>>> ..
>>>     template <class T>
>>>     void work(T* p);
>>> }
>>>
>>> and then something like:
>>>
>>> template <bool STRDEDUP>
>>> class ShenandoahTraversalDedupClosure : public 
>>> ShenandoahTraversalSuperClosure<STRDEDUP> {
>>>
>>> I am not totally sure about how to stitch it together, but something
>
>>> like this should work? Or maybe it's not worth all the hassle. ?
>>>
>>> (Infact, I suspect something like the above would be possible for
>the 
>>> metadata flag too...)
>>>
>>> Roman
>>>
>> 
>> 
>> Ah, one weirdo in this scheme is the definition of work(), which
>would 
>> look something like:
>> 
>> template <bool STRDEDUP>
>> template <class T>
>> inline void ShenandoahTraversalSuperClosure::work(T* p) {
>
>What's advantage of this style?
>
>Thanks,
>
>-Zhengyu
>
>
>> 
>> Roman

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


More information about the shenandoah-dev mailing list