RFR: 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp [v4]

[Mark Sheppard]

On Fri, 10 Feb 2023 01:53:18 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 74:
>> 
>>> 72:     public void useExportObject(String name, Object obj, int expectedFilterCount) throws RemoteException {
>>> 73:         try {
>>> 74:             impl = RemoteImpl.create();
>> 
>> I'd prefer to use  ReachabilityFence at the end of the try block to keep the nested scoping.
>> ```Reference.reachabilityFence(impl);```
>
> I just tested it and it really be OK, I'll submit a new commit.

yes, this mitigates the issue within the test,  and alls good.
BUT it still leave an open question as to why the behaviour of the test is different for the -Xcomp mode and the interpretative mode?
I think it would be reasonable to expect both modes to behave the same. As such, that the compile mode should generate a fence or whatever to guarantee that the impl remain a strong reference until it goes out of scope at the end of the try block ?
Thus is the case in non -Xcomp mode, but in -Xcomp the status of the impl reference is accelerate to to being unreachable and a candidate for garbage collection ?
Is it not a hotspot compiler issue or the component area responsible for -Xcomp ?

-------------

PR: https://git.openjdk.org/jdk/pull/12399