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? Thanks On Mon, Nov 23, 2015 at 11:38 AM, Paul Sandoz <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. > >
