RFR: Can not dedup string inside write barrier

Zhengyu Gu zgu at redhat.com
Mon Nov 6 16:20:36 UTC 2017



On 11/06/2017 10:46 AM, Aleksey Shipilev wrote:
> On 11/06/2017 04:25 PM, Zhengyu Gu wrote:
>> On 11/06/2017 10:13 AM, Aleksey Shipilev wrote:
>>> On 11/06/2017 03:59 PM, Zhengyu Gu wrote:
>>>> Can not perform String deduplication inside a write barrier, as it takes lock, that violates write
>>>> barrier's leaf call constraint.
>>>>
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/strdedup_wb/webrev.00/
>>>
>>> Okay, but minor nits:
>>>
>>>    *) I think there is no need for templates, because the method is already slow-path. A simple
>>> boolean arg would be enough? This will simplify backports too, because the signature change would be
>>> needed everywhere, instead of blind substitution of evacuate_object.
>> Yes, for write barrier, it is slow path. However, it is also used by GC, that can have some impact (?).
> 
> If we care as much, then ShenandoahStringDedup::is_enabled() check is already on critical path
> there. So, do a boolean flag, and hide it *after* the ShenandoahStringDedup::is_enabled() check?
> 
>   373   if (ShenandoahStringDedup::is_enabled() && !from_write_barrier &&
>   374       java_lang_String::is_instance_inlined(copy_val)) {
Okay.

http://cr.openjdk.java.net/~zgu/shenandoah/strdedup_wb/webrev.02/index.html

Thanks,

-Zhengyu


> 
> -Aleksey
> 


More information about the shenandoah-dev mailing list