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

Roger Riggs rriggs at openjdk.org
Fri Feb 10 17:04:14 UTC 2023


On Fri, 10 Feb 2023 12:13:13 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> 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 ?
> 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.

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

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


More information about the core-libs-dev mailing list