RFR: Can not dedup string inside write barrier

[Aleksey Shipilev]

On 11/06/2017 05:20 PM, Zhengyu Gu wrote:
> 
> 
> 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

Looks good.

-Aleksey