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

[Mark Sheppard]

On Fri, 10 Feb 2023 17:00:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 ?
>> This 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 ?
>
> @msheppar It depends on the timing of GC and the unpredictable interactions between the compiler and gc.
> If gc is particularly aggressive (as may be stimulated by -Xcomp), it may determine that the impl is no longer referenced even though it seems to be in the middle of the method.

Would this behaviour be covered by the JLS and JVM specs ?

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

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