RFR (M): 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC overhead
manc at google.com
Wed Dec 12 10:30:22 UTC 2018
Addressed several comments. New webrev:
Diff from webrev.00:
> > Assuming that all collectors want to implement this, and actually
> > need to I am leaning towards doing so. However the ZGC/Shenandoah
> > people might object to this.
I haven't moved the GCOverheadChecker instance to CollectedHeap yet.
Should I wait for ZGC/Shenandoah people to give some green light?
> Creating a CSR and getting it approved is not a big deal; it may even
> be useful as it clearly communicates the change to the users.
> Additionally I think due to that translation table I mentioned, the old
> name can still be used I think.
As for the hsperfdata counter sun.gc.policy.gcTimeLimitExceeded, I found two
(a) The translation table in aliasmap seems to mainly target JDK-internal
usage of the counters.
Only the PerfDataBufferImpl.findByName() method makes use of the aliasmap.
There are use cases that doesn't work with the aliasmap. E.g.:
$ jstat -J-Djstat.showUnsupported=true -name java.ci.totalTime <pid> //
$ jstat -J-Djstat.showUnsupported=true -name hotspot.ci.total.time <pid> //
This doesn't work
This is because the "jstat -name" would invoke the
which does not take the aliasmap into account.
In addition, there are independent implementations that read
file directly, e.g.:
And Google internally has a Java implementation that does the job (but uses
These tools do not support aliasmap.
As for this counter, fortunately I found it hardly used anywhere in OpenJDK
or across Google's depot.
And its current implementation is not that useful, as described below.
(b) This counter contains a boolean value that is set at every GC. This
makes its usefulness limited,
as it is very hard to catch the moment when it is set to 1. When a full GC
sets it to 1 and
throws an OOM exception due to GC overhead exceeded, the JVM could
another full GC and reset the counter to 0, then terminates due to the OOM
If -XX:PerfDataSaveFile=foo.hsperf is set, foo.hsperf would contain 0 for
this counter in this case,
which is quite unexpected.
I'd propose to change this counter to a cumulative counter, i.e, the total
number of GCs that trigger
GC-overhead-limit-exceeded event, and rename this counter as the same time.
I think it is cleaner to do this change in a separate RFE and CSR. What do
More information about the hotspot-dev