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