CRR (re-opened / M): 7075646: G1: fix inconsistencies in the monitoring data
Tony Printezis
tony.printezis at oracle.com
Wed Sep 21 22:34:18 UTC 2011
(resending to the correct list this time....)
Hi all,
I'm re-opening this change for code review:
http://cr.openjdk.java.net/~tonyp/7075646/webrev.3/
Here's a quick recap of the changes:
a) The jstat tool assumes that none of the spaces have 0 capacity. In G1
the assumption does not always hold (i.e., where no survivor regions are
allocated, the survivor space has 0 capacity). This causes jstat to
display an unexpected character (?) instead of the correct occupancy
percentage of a space. To get round this problem I now artificially pad
all capacities, when reported through jstat, to ensure that no capacity
is 0.
b) The jstat counters for the young / old gen capacity were not updated.
Those counters are now updated correctly.
Unfortunately, I had to re-architect the way G1 calculates the various
sizes reported by the monitoring frameworks to ensure that we do minimal
work when a new eden region is allocated (e.g., update exactly the eden
occupancy counter, not having to update all the sizes and counters). The
new version calculates all the sizes synchronously in well-defined
places (all sizes: end of GC, end of hum object allocation, eden
occupancy: after an eden region allocation) and stores them in fields.
The consumers of the data only read the fields when they need the
values, i.e., they do not need to recalculate anything.
I also tidied up the GenerationCounters class (there are now two clear
constructors, one for uses with a VirtualSpace, one without) and the G1
memory pool classes (we had several static wrapper methods that
calculated some of the sizes, but these are not needed any more as the
calculations are now done elsewhere).
Tony
More information about the hotspot-gc-dev
mailing list