Reference.reachabilityFence

[Peter Levart]

Hi Paul,

Good to see this getting in. Cleaner API depends on it ;-)

On 11/23/2015 05:38 PM, Paul Sandoz wrote:
> Hi,
>
> Please review the addition of Reference.reachabilityFence contributed by Aleksey, Doug and myself:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/>
>
> The implementation approach marks the method Reference.reachabilityFence as not inline-able, thereby “keeping alive” an object passed to the method until at least after the method call.
>
> The testing approach i have taken is to verify that the method does not get inlined either in C1 or C2. The test approach seems fragile (as fragile as the accessor-based test i code-cargo-culted from) but passes ok through JPRT.
>
> I could not find a suitable mechanism in WhiteBox. Is there a more reliable mechanism to determine what methods are inlined into a compiled method?
>
> There is another testing approach in the VarHandles sandbox:
>
>    http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/433114b32d2d#l2.2 <http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/433114b32d2d#l2.2>
>
> But i am not confident that the test can be run within a reasonable time and reliably on all platforms and VM modes.
>
> Paul.
>

The problem of this other approach is that you constantly invoke 
System.gc(), so your time to warm-up the code to get it compiled is big. 
Why don't you allow the loop to run faster for some warm-up time and 
kick GC in only after that. Like:

http://cr.openjdk.java.net/~plevart/misc/ReachabilityFence/ReachabilityFence.java

This works reliably on Linux and only takes not much more than 200ms per 
test.

You are also relying on JIT to do on-stack replacement. It seems to work 
for all modes (besides interpreter-only).

Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151123/3e89fb81/attachment-0001.html>