RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing

[Roman Kennke]

>> In some paths, we currently check GC state 3 times before enqueueing an oop in SATB buffer: 1.
>> conc-mark in progress (global or local), 2. SATB active (global) 3. SATB active (local). This should
>> be streamlined to only do one check, and consistently check conc-mark-in-progress only.
>>
>> This can be taken even further for arraycopy pre-barriers and arraycopy-loops, where the check can
>> be done once for the whole operation. In arraycopy barriers code, we can also 'inline' the current
>> thread and marking context objects, instead of fetching them for every array element.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8221751
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.00/
> 
> Looks okay.
> 
> *) In ShenandoahBarrierSet::write_ref_array_pre_work, shouldn't all new code go under the
> _heap->is_concurrent_mark_in_progress branch?
> 
> 
> *) Indenting nit in shenandoahRuntime.cpp.
> 
>    52   shenandoah_assert_correct(NULL, orig);
>    53   // store the original value that was in the field reference
>    54 assert(ShenandoahThreadLocalData::satb_mark_queue(thread).is_active(), "Shouldn't be here
> otherwise");
>    55   ShenandoahThreadLocalData::satb_mark_queue(thread).enqueue_known_active(orig);
> 

I noticed that AArch64 assembly stubs don't check marking-in-progess at 
all, and x86 asm stub checks the SATB-active and not the gc-state like 
we do everywhere else. I added the aarch64 check, and changed x86 to 
check gc-state. I also added checks for count==0, in which case we don't 
even need to call out at all. (And it is surprisingly common too.)

http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.02/

Testing: Passes hotspot_gc_shenandoah both x86 and aarch64

Ok?

Roman