On 7/26/18 12:53 PM, JC Beyler wrote:
Hi all,
As we fixed the HeapMonitorTest to not fail from time to time, there
seems to be the same issue and risk in HeapMonitorGCTest. Could
someone review the similar fix:
Webrev: http://cr.openjdk.java.net/~jcbeyler/8208251/webrev.00/
<http://cr.openjdk.java.net/%7Ejcbeyler/8208251/webrev.00/>
test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCTest.java
No comments.
Thumbs up!
Perhaps consider filing a bug to refactor HeapMonitorTest and
HeapMonitorGCTest.java so that they share code... then we won't
have to fix the same bug in two places...
Dan
Bug: https://bugs.openjdk.java.net/browse/JDK-8208251
The risk is that the last interval is too big and no sampled object is
live after the allocation method. If a GC happens before the check for
sample code, it is possible no live objects still exist.
The solution is to reduce the sampling interval to make it highly
unlikely for no samples to happen in any allocation iteration, keeping
at least one sampled object live. But also check the GC'd objects in
the system in case they did actually all already get GC'd.
Thanks,
Jc
