TEST_BUG: java/rmi/dgc/dgcAckFailure/DGCAckFailure.java fails in Xcomp mode

David Holmes added a comment - 2013-10-29 04:06
The failure mode of the test is:

java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at DGCAckFailure_Stub.returnRemote(DGCAckFailure_Stub.java:56)
at DGCAckFailure.main(DGCAckFailure.java:80)

The code in question does this:

        Remote impl = new DGCAckFailure();
        ReferenceQueue refQueue = new ReferenceQueue();
        Reference weakRef = new WeakReference(impl, refQueue);
        ReturnRemote stub =
            (ReturnRemote) UnicastRemoteObject.exportObject(impl);
        System.err.println("remote object exported; stub = " + stub);

        try {
            Object wrappedStub = stub.returnRemote(); <= exception thrown here.

It appears that when everything is compiled with Xcomp, and the client compiler, the lifetime of the impl object is not what is normally encountered. We have seen similar issues before. Changing the test so that the local:

 Remote impl = new DGCAckFailure();

becomes a static field:

static Remote impl = new DGCAckFailure();

fixes the problem.

While not intuitive this is a test bug. When working with weakreferences etc you need to be extremely careful if your only strong reference is a local as this can be optimized away:

http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6.1

"Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.

Another example of this occurs if the values in an object's fields are stored in registers. The program may then access the registers instead of the object, and never access the object again. This would imply that the object is garbage. Note that this sort of optimization is only allowed if references are on the stack, not stored in the heap. "
-----

Hence changing from a local stack variable to a static field (heap variable) fixes the problem.