RFR: 8240873: Shenandoah: Short-cut arraycopy barriers

[Roman Kennke]

On 3/12/20 12:04 PM, Aleksey Shipilev wrote:
> On 3/12/20 12:04 PM, Roman Kennke wrote:
>>> *) Wouldn't it make more sense to do acquire/release in (get|set)_update_watermark?
>>
>> Hmm ok. This requires making the field. I am not sure if the cast in
>> get_update_watermark() is ok?
> 
> I don't quite understand why cast is needed. There are already _critical_pins and _live_data fields
> that are atomic, why can't we do the same?
> 

Turns out that:

volatile HeapWord* _update_watermark;

is not the same as:

HeapWord* volatile _update_watermark;

The former means 'a pointer to a volatile HeapWord', the latter 'a
volatile pointer to a HeapWord'. We need the latter.

Testing showed an occasional failure caused by piggy-backing updaterefs
on marking: it would skip updating when taking the marking-shortcut.
While it is not really relevant anymore, I changed the conditions a bit
to not blindly return in the arraycopy-pre-barrier, but do the check for
updating independently. Overall a good example why it was a good move to
get rid of the piggy-backing. It causes more maintenance for no real
benefit.

http://cr.openjdk.java.net/~rkennke/JDK-8240873/webrev.03/

Passes all tests in hotspot_gc_shenandoah

Good now?

Roman