8202466: Test serviceability/tmtools/jstat/GcTest01.java fails: Number of concurrent GC events is 1, but CGCT is 0

Chris Plummer chris.plummer at oracle.com
Thu May 3 15:26:20 UTC 2018


Hi Yasumasa,

I only see the one reported failure in our recent test history for this 
test, so it doesn't look like it happens every time. I'll try running 
the test on the machine it failed on, both with the binary it failed 
with and a more recent binary.

best regards,

chris

On 5/3/18 4:48 AM, Yasumasa Suenaga wrote:
> FYI: jdk-11-ea+11 passed GcTest01.java
> https://download.java.net/openjdk/testresults/11/archives/11/diff-hotspot-10-11.txt
>
>
> On 2018/05/02 21:46, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> I've tried to fix 8202466, but I do not yet certain which solution is 
>> the best for it.
>> So I want your opinion for it.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8202466
>>
>> David reports serviceability/tmtools/jstat/GcTest01.java failed in 
>> Mach5. It seems to appear on OS X only.
>> He has shared jtreg report, and I found as below:
>>
>> ```
>> stdout: S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT 
>> CGC CGCT GCT
>>   0.0 0.0 0.0 0.0 3072.0 0.0 11264.0 2825.6 9472.0 9003.3 1024.0 
>> 845.3 26 0.204 3 0.292 1 0.000 0.497
>> ```
>>
>> YGCT: 0.204
>> FGCT: 0.292
>> CGCT: 0.000
>>
>>   GCT: 0.497
>>
>> I guess this failure was caused by rounding error because (YGCT + 
>> FGCT + CGCT) < GCT.
>> CGC is 1, so CGC operation might finish in very short time.
>>
>>
>> GcTest01.java:
>> http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcTest01.java#l57
>>
>> GcCauseTest01.java:
>> http://hg.openjdk.java.net/jdk/jdk/file/4da7dce7e2bf/test/hotspot/jtreg/serviceability/tmtools/jstat/GcCauseTest01.java#l53
>>
>> GcTest01 and GcCauseTest01 are very similar, but GcCauseTest01 passed.
>> Both tests use GcProvoker::provokeGc() to inflate memory usage. So I 
>> wonder why GcTest01 just only failed.
>> I guess we might encounter similar issue(s) in the future if we get 
>> more fast machines.
>>
>> Hence I think we can take two approaches as below:
>>
>>    1. Add all tests in serviceability/tmtools/jstat to ProblemList.
>>    2. Change all JstatGc*Tool to use custom jstat_options - to show 
>> raw values in PerfCounters
>>
>>
>> What do you think?
>> I can start to work for it if they are OK.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>




More information about the serviceability-dev mailing list