RFR 8209844: MemberNameLeak.java fails when ResolvedMethod entry is not removed

[David Holmes]

Hi Patricio,

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.

Cheers,
David

> Webrev URL: http://cr.openjdk.java.net/~pchilanomate/8209844.01/webrev
> Bug URL: https://bugs.openjdk.java.net/browse/JDK-8209844
> 
> Thanks,
> Patricio