RFR (XS) 8208251: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCCMSTest.java fails intermittently on Linux-X64

[JC Beyler]

Here you are Serguei:

http://cr.openjdk.java.net/~jcbeyler/8208251/webrev.01/

Thanks for the push!
Jc

Ps: @Daniel I created the issue and assigned it to me (
https://bugs.openjdk.java.net/browse/JDK-8208352)

On Thu, Jul 26, 2018 at 11:11 AM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> Jc,
>
> Could you send me a patch?
> I'll sponsor the push.
>
> Thanks,
> Serguei
>
>
> On 7/26/18 11:05, Daniel D. Daugherty wrote:
>
> 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/
>
>
>
> 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
>
>
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180726/fe26d6b9/attachment.html>