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