RFR: Uses keep_alive_barrier to keep deduped char array alive

[Roman Kennke]

Am 11.10.2017 um 21:34 schrieb Zhengyu Gu:
>
>> Also, the whole block:
>>
>> 384 if (UseShenandoahGC) {
>> 385 oopDesc::bs()->keep_alive_barrier(existing_value);
>> 386 existing_value = 
>> (typeArrayOop)oopDesc::bs()->read_barrier(existing_value);
>> 387 } else {
>>   388       // Enqueue the reference to make sure it is kept alive. 
>> Concurrent mark might
>>   389       // otherwise declare it dead if there are no other strong 
>> references to this object.
>>   390       G1SATBCardTableModRefBS::enqueue(existing_value);
>> 391 } Should be just: oopDesc::bs()->keep_alive_barrier(existing_value);
>>
>> For G1 and Shenandoah under conc-mark, this enqueues the object in 
>> SATB, for Shenandoah under conc-partial it does the WB. As I said 
>> above, I don't think the RB is needed. I would be very surprised.
>>
> Ok, let me clear my thoughts here.
>
> If we do SATB barrier, that will ensure existing_value alive.
In G1, and Shenandoah (but only during conc-mark, not during conc-partial).
> However, if we do keep_alive_barrier, the existing_value could be 
> evacuated, but we still hold old oop here, right? then we can end up 
> dead oop after recycle?
No, because there cannot be a safepoint between keep_alive_barrier() and 
subsequent uses. We may hold a pointer to a from-space object, but that 
should be ok if all subsequent uses do their barriers right. There is 
only one subsequent use before the oop goes out of scope, and that is

java_lang_String::set_value(java_string, typeArrayOop(existing_value));

which does the correct barrier (i.e. storeval-barrier). Everything 
should be fine.

Roman