On Fri, 10 Feb 2023 01:53:18 GMT, SUN Guoyun <d...@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
