Hi Yasumasa,
On 5/2/18 5:46 AM, 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.
I don't think we want to do that at this time since this is a newly
introduced problem, and is intermittent. So the goal would be to fix it
in the near term without problem listing it.
2. Change all JstatGc*Tool to use custom jstat_options - to show raw
values in PerfCounters
I'm not sure what is meant by this.
thanks,
Chris
What do you think?
I can start to work for it if they are OK.
Thanks,
Yasumasa
