RFR: Shenandoah critical native support

Roman Kennke rkennke at redhat.com
Wed Mar 28 19:28:47 UTC 2018


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?

- 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 :-)

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




More information about the shenandoah-dev mailing list