RFR: Shenandoah critical native support

[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.

> 
> - 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?

Thanks,

-Zhengyu


> 
> Patch looks good!
> 
> Cheers, Roman
> 
> 
> 
>> The implementation is X64 only (Linux and Windows).
>>
>> It appears that aarch64 never implemented critical native support for
>> any GC (sharedRuntime_aarch64: check_needs_gc_for_critical_native() {
>> Unimplemented(); })
>>
>> The implementation intercepts inbound array arguments and pins them just
>> before unpacks them. It also reuses oop handle area that is reserved for
>> GC safepointing GC before entering critical session in default
>> implementation, it saves register based inbound arguments there, so they
>> can be found for unpinning after method call.
>>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/sh-critical-natives/webrev.00/index.html
>>
>>
>> Test:
>>
>>    hotspot_gc_shenandoah
>>      Linux x64: fastdebug and release
>>      Windows: release (really slow running inside Vbox)
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>
>>
>>
> 
>