RFR: Fixed two string dedup issues
Zhengyu Gu
zgu at redhat.com
Tue Oct 10 16:52:06 UTC 2017
On 10/10/2017 12:36 PM, Aleksey Shipilev wrote:
> On 10/10/2017 06:35 PM, Zhengyu Gu wrote:
>> On 10/10/2017 12:00 PM, Aleksey Shipilev wrote:
>>> On 10/10/2017 03:47 PM, Zhengyu Gu wrote:
>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/shenandoah/strdedup_fix/webrev.01/index.html
>>> Can you explain a little more why do we need to filter for only Shenandoah safepoints? The string
>>> would only be queued, why does it matter if we are not in Shenandoah safepoint?
>> Okay, added comments.
>>
>
> I mean, can you explain here so I can understand what failure scenario you have in mind?
String dedup protocol requires queuing during GC safepoints (where it
suspends deplication thread) and deduplicating strings outside GC
safepoints.
G1 does all queuing during evacuation at GC safepoints, just as what we
do with full GC.
Shenandoah evacuates objects inside and outside GC safepoints, so we
need to know if it is a GC or none GC safepoint, we only queue strings
if it is a GC safepoint, otherwise, we disregard the safepoint.
Let me know if it is still not clear.
Thanks,
-Zhengyu
>
> -Aleksey
>
More information about the shenandoah-dev
mailing list