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