RFR: Shenandoah critical native support

[Roman Kennke]

Am 28.03.2018 um 22:11 schrieb Zhengyu Gu:
> 
> 
> On 03/28/2018 03:28 PM, Roman Kennke wrote:
>> Wow, this is really cool.
>>
>> Questions:
>> Thinking about upstreaming:
>>
>> - Could it use the existing pin_object() / unpin_object() APIs? Maybe
>> assuming we get rid of the upstream GCLocker interaction again?
> 
> Yes, I would prefer to remove GCLocker from pin/unpin object, before use
> it. With current default implementation, it will likely run into trouble
> if pin_arrays_for_critical_native() return true, but forget to override
> pin/unpin_object methods.

Yes, this should be reverted.

>> - Speaking of GCLocker interaction? I assume it amounts to a no-op or
>> bogus counter if GC ignores GCLocker, as is the case for pin_object()
>> and unpin_object() in JNI.
>>
>> You're probably aware of:
>> https://bugs.openjdk.java.net/browse/JDK-8199868
>>
>> Feel free to take it :-)
> 
> Okay, let's test a little before purpose upstream.
> 
> BTW, how to deal with aarch64? file upstream bug or just let aph/adinn
> know?

Both :-) File upstream bug *and* let aph/adinn know ;-)

Please push your change!
Thanks, Roman