Hi Peter, Reachability is not a side effect the compiler should preserve. In other words, if a method has no other side effects and is eliminated, I'd expect this to shorten the live range of any of its, say, arguments assuming no further use of them. If that doesn't happen, I'd consider that a bug (or at least missed optimization).
sent from my phone On Nov 23, 2015 6:09 PM, "Peter Levart" <peter.lev...@gmail.com> wrote: > Hi, > > On 11/23/2015 05:50 PM, Vitaly Davidovich wrote: > > Hi Paul, > > Glad you guys are addressing this. > > It looks like C1 and C2 will actually call this method. Is the longer term > plan to teach the compilers that this method does not need to be called but > rather expand the live range of the reference? > > > It seems that (at least sometimes) compiler(s) are able to do just that. > > With the following test: > > > http://cr.openjdk.java.net/~plevart/misc/ReachabilityFence/ReachabilityFence2.java > > Even a simple empty static method "inlineableNoOp(Object)" acts as a > reachabilityFence. > > When invoked with: > > -Dpremature=true > -XX:+IgnoreUnrecognizedVMOptions > -showversion > -server > -XX:-TieredCompilation > -Xbatch > -Xcomp > -XX:+PrintCompilation > -XX:+UnlockDiagnosticVMOptions > -XX:+PrintInlining > > > ...we can see that inlineableNoOp() is in fact inlined, but the test still > passes (if the call to inlineableNoOp() is removed it fails!) > > > 2771 1161 b ReachabilityFence2::fenced (38 bytes) > @ 0 java.lang.System::nanoTime (0 bytes) > (intrinsic) > @ 9 ReachabilityFence2::fencedTry (30 > bytes) inline (hot) > @ 4 > ReachabilityFence2$MyFinalizeable::<init> (16 bytes) inline (hot) > @ 1 java.lang.Object::<init> (1 bytes) > inline (hot) > @ 9 > java.util.concurrent.atomic.AtomicBoolean::<init> (5 bytes) inline (hot) > @ 1 java.lang.Object::<init> (1 > bytes) inline (hot) > ! @ 14 ReachabilityFence2::doGc (22 bytes) > inline (hot) > @ 18 > java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 24 ReachabilityFence2::inlineableNoOp (1 > bytes) inline (hot) > @ 25 java.lang.System::nanoTime (0 bytes) > (intrinsic) > @ 9 ReachabilityFence2::fencedTry (30 > bytes) inline (hot) > @ 4 > ReachabilityFence2$MyFinalizeable::<init> (16 bytes) inline (hot) > @ 1 java.lang.Object::<init> (1 bytes) > inline (hot) > @ 9 > java.util.concurrent.atomic.AtomicBoolean::<init> (5 bytes) inline (hot) > @ 1 java.lang.Object::<init> (1 > bytes) inline (hot) > ! @ 14 ReachabilityFence2::doGc (22 bytes) > inline (hot) > @ 8 java.lang.System::gc (7 bytes) > inline (hot) > @ 0 java.lang.Runtime::getRuntime (4 > bytes) inline (hot) > @ 3 java.lang.Runtime::gc (0 bytes) > native method > @ 14 java.lang.Thread::sleep (0 bytes) > native method > @ 18 > java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 24 ReachabilityFence2::inlineableNoOp (1 > bytes) inline (hot) > > > When invoked with: > > -Dpremature=true > -XX:+IgnoreUnrecognizedVMOptions > -showversion > -server > -XX:TieredStopAtLevel=1 > -Xbatch > -Xcomp > -XX:+PrintCompilation > -XX:+UnlockDiagnosticVMOptions > -XX:+PrintInlining > > > The test passes and prints: > > 904 837 b 1 ReachabilityFence2::fenced (38 bytes) > @ 0 java.lang.System::nanoTime (0 bytes) > intrinsic > @ 9 ReachabilityFence2::fencedTry (30 > bytes) > @ 4 > ReachabilityFence2$MyFinalizeable::<init> (16 bytes) > @ 1 java.lang.Object::<init> (1 bytes) > @ 9 > java.util.concurrent.atomic.AtomicBoolean::<init> (5 bytes) > @ 1 java.lang.Object::<init> (1 > bytes) > ! @ 14 ReachabilityFence2::doGc (22 bytes) > @ 8 java.lang.System::gc (7 bytes) > @ 0 java.lang.Runtime::getRuntime (4 > bytes) > @ 3 java.lang.Runtime::gc (0 > bytes) native method > @ 14 java.lang.Thread::sleep (0 > bytes) native method > @ 18 > java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) > @ 24 ReachabilityFence2::inlineableNoOp > (1 bytes) > @ 25 java.lang.System::nanoTime (0 > bytes) intrinsic > > > This seems to indicate that for establishing a reachability even > inlineable no-op (empty) method with single argument is enough. > > It might not be enough in every situation, but what this means is that it > will be very difficult to write a positive test for > Reference.reachabilityFence(Object) when we can't write a negative test > with a simple inlineable static no-op method. I haven't been able to > come-up with a form of code that passes the negative test (nonFenced) and > call the inlineableNoOp in the process. > > > Regards, Peter > > > > Thanks > > On Mon, Nov 23, 2015 at 11:38 AM, Paul Sandoz <paul.san...@oracle.com> > <paul.san...@oracle.com> > 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-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 > > But i am not confident that the test can be run within a reasonable time > and reliably on all platforms and VM modes. > > Paul. > > > > >
