RFR 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed
david.holmes at oracle.com
Mon Sep 3 04:27:34 UTC 2018
On 29/08/2018 7:52 AM, Patricio Chilano wrote:
> Hi all,
> Could you review this change that addresses the intermittent failure of
> test MemberNameLeak.java after 8206423 ?
> The test had intermittent failures due to the ServiceThread not being
> able to clean up the resolved method table before the process exited.
> Now a counter is used to guarantee entries in the table are removed
> before exiting. Also variables _oops_removed and _oops_counted were
> declared local in ResolvedMethodTable::unlink() since they are not used
> outside it.
I'm somewhat surprised this test didn't already fail intermittently as
it assumes a single explicit System.gc() is enough to trigger the
cleanup it is checking for! If that assumption is not valid then the
test will now hang (in a busy polling loop!) until the test harness
times it out and forcibly terminates it. (Previously it would have
failed due to the missing output immediately after the gc() call returned.)
Exposing the actual change to the resolved method table via the WB API
seems quite reasonable, but in general busy polling loops should be
avoided by inserting short sleeps between polls.
> Webrev URL: http://cr.openjdk.java.net/~pchilanomate/8209844.01/webrev
> Bug URL: https://bugs.openjdk.java.net/browse/JDK-8209844
More information about the hotspot-runtime-dev