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