RFR: 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp [v4]
Mark Sheppard
msheppar at openjdk.org
Thu Feb 9 12:31:43 UTC 2023
On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:
>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>>
>> This PR fix the issue, Please help review it.
>>
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
>
> 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp
As you have shown moving the impl to a member variable of the test, allows the test to pass and means that when the reaper runs it doesn't find a weak reference for the RemoteImpl. We can see this in trace below ... there are no remove call on ObjectTable
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Target pinImpl
FINER: MainThread: strongRef = sun.rmi.transport.DGCImpl at 7cbf0dfe
Feb 09, 2023 12:03:13 PM sun.rmi.transport.DGCImpl$2 run
FINER: MainThread: add object [0:0:0, 2]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7fff, -828094982909796927]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ffd, 1016769954862579574]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ffb, 5046449780262743815]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff9, -5609899494232426191]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff7, -3723530497788482934]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff5, 26547078264881776]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff3, 893326842025149942]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff1, -5974039217477050622]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7fef, -8933988202720453193]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7fed, -3244609101583748901]
STATUS:Passed.
I have an instrumented build and we can see that the Reaper's reapQueue is empty, no weak refreences, when it runs first time
ObjectTable::incrementKeepAliveCount Reaper Thread started
ObjectTable::Reaper::run ENTER thread Thread[#23,RMI Reaper,5,system]
ObjectTable::Reaper::run check reapQueue Thread[#23,RMI Reaper,5,system]
ObjectTable::incrementKeepAliveCount gcInterval == 3600000
> After `-Dsun.rmi.dgc.logLevel=VERBOSE`, test run passed. I don't understand why, you know?
as it's a subtle race condition within the test, the logging can delay when the removal event happens
If declaring impl as a member variable works, and mitigates the failure, then that's a reasonable work around ... I expect Roger will comment on this further.
-------------
PR: https://git.openjdk.org/jdk/pull/12399
More information about the core-libs-dev
mailing list