graal-jvmci-8: src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp comparison

comparison src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp @ 3980:8229bd737950

7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc

author	tonyp
date	Fri, 23 Sep 2011 16:07:49 -0400
parents	b52782ae3880
children	81aa07130d30

comparison

equal deleted inserted replaced

-:4dfb2df418f2
+:8229bd737950
 #define SHARE_VM_GC_IMPLEMENTATION_G1_G1MONITORINGSUPPORT_HPP
 #include "gc_implementation/shared/hSpaceCounters.hpp"
 class G1CollectedHeap;
-class G1SpaceMonitoringSupport;
+// Class for monitoring logical spaces in G1. It provides data for
-// Class for monitoring logical spaces in G1.
+// both G1's jstat counters as well as G1's memory pools.
-// G1 defines a set of regions as a young
+//
-// collection (analogous to a young generation).
+// G1 splits the heap into heap regions and each heap region belongs
-// The young collection is a logical generation
+// to one of the following categories:
-// with no fixed chunk (see space.hpp) reflecting
+//
-// the address space for the generation.  In addition
+// * eden      : regions that have been allocated since the last GC
-// to the young collection there is its complement
+// * survivors : regions with objects that survived the last few GCs
-// the non-young collection that is simply the regions
+// * old       : long-lived non-humongous regions
-// not in the young collection.  The non-young collection
+// * humongous : humongous regions
-// is treated here as a logical old generation only
+// * free      : free regions
-// because the monitoring tools expect a generational
+//
-// heap.  The monitoring tools expect that a Space
+// The combination of eden and survivor regions form the equivalent of
-// (see space.hpp) exists that describe the
+// the young generation in the other GCs. The combination of old and
-// address space of young collection and non-young
+// humongous regions form the equivalent of the old generation in the
-// collection and such a view is provided here.
+// other GCs. Free regions do not have a good equivalent in the other
-//
+// GCs given that they can be allocated as any of the other region types.
-// This class provides interfaces to access
+//
-// the value of variables for the young collection
+// The monitoring tools expect the heap to contain a number of
-// that include the "capacity" and "used" of the
+// generations (young, old, perm) and each generation to contain a
-// young collection along with constant values
+// number of spaces (young: eden, survivors, old). Given that G1 does
-// for the minimum and maximum capacities for
+// not maintain those spaces physically (e.g., the set of
-// the logical spaces.  Similarly for the non-young
+// non-contiguous eden regions can be considered as a "logical"
-// collection.
+// space), we'll provide the illusion that those generations and
-//
+// spaces exist. In reality, each generation and space refers to a set
-// Also provided are counters for G1 concurrent collections
+// of heap regions that are potentially non-contiguous.
-// and stop-the-world full heap collecitons.
+//
-//
+// This class provides interfaces to access the min, current, and max
-// Below is a description of how "used" and "capactiy"
+// capacity and current occupancy for each of G1's logical spaces and
-// (or committed) is calculated for the logical spaces.
+// generations we expose to the monitoring tools. Also provided are
-//
+// counters for G1 concurrent collections and stop-the-world full heap
-// 1) The used space calculation for a pool is not necessarily
+// collections.
-// independent of the others. We can easily get from G1 the overall
+//
-// used space in the entire heap, the number of regions in the young
+// Below is a description of how the various sizes are calculated.
-// generation (includes both eden and survivors), and the number of
+//
-// survivor regions. So, from that we calculate:
+// * Current Capacity
 //
-//  survivor_used = survivor_num * region_size
+//    - heap_capacity = current heap capacity (e.g., current committed size)
-//  eden_used     = young_region_num * region_size - survivor_used
+//    - young_gen_capacity = current max young gen target capacity
-//  old_gen_used  = overall_used - eden_used - survivor_used
+//          (i.e., young gen target capacity + max allowed expansion capacity)
-//
+//    - survivor_capacity = current survivor region capacity
-// Note that survivor_used and eden_used are upper bounds. To get the
+//    - eden_capacity = young_gen_capacity - survivor_capacity
-// actual value we would have to iterate over the regions and add up
+//    - old_capacity = heap_capacity - young_gen_capacity
-// ->used(). But that'd be expensive. So, we'll accept some lack of
+//
-// accuracy for those two. But, we have to be careful when calculating
+//    What we do in the above is to distribute the free regions among
-// old_gen_used, in case we subtract from overall_used more then the
+//    eden_capacity and old_capacity.
-// actual number and our result goes negative.
+//
-//
+// * Occupancy
-// 2) Calculating the used space is straightforward, as described
+//
-// above. However, how do we calculate the committed space, given that
+//    - young_gen_used = current young region capacity
-// we allocate space for the eden, survivor, and old gen out of the
+//    - survivor_used = survivor_capacity
-// same pool of regions? One way to do this is to use the used value
+//    - eden_used = young_gen_used - survivor_used
-// as also the committed value for the eden and survivor spaces and
+//    - old_used = overall_used - young_gen_used
-// then calculate the old gen committed space as follows:
+//
-//
+//    Unfortunately, we currently only keep track of the number of
-//  old_gen_committed = overall_committed - eden_committed - survivor_committed
+//    currently allocated young and survivor regions + the overall used
-//
+//    bytes in the heap, so the above can be a little inaccurate.
-// Maybe a better way to do that would be to calculate used for eden
+//
-// and survivor as a sum of ->used() over their regions and then
+// * Min Capacity
-// calculate committed as region_num * region_size (i.e., what we use
+//
-// to calculate the used space now). This is something to consider
+//    We set this to 0 for all spaces. We could consider setting the old
-// in the future.
+//    min capacity to the min capacity of the heap (see 7078465).
 //
-// 3) Another decision that is again not straightforward is what is
+// * Max Capacity
-// the max size that each memory pool can grow to. One way to do this
+//
-// would be to use the committed size for the max for the eden and
+//    For jstat, we set the max capacity of all spaces to heap_capacity,
-// survivors and calculate the old gen max as follows (basically, it's
+//    given that we don't always have a reasonably upper bound on how big
-// a similar pattern to what we use for the committed space, as
+//    each space can grow. For the memory pools, we actually make the max
-// described above):
+//    capacity undefined. We could consider setting the old max capacity
-//
+//    to the max capacity of the heap (see 7078465).
-//  old_gen_max = overall_max - eden_max - survivor_max
+//
-//
+// If we had more accurate occupancy / capacity information per
-// Unfortunately, the above makes the max of each pool fluctuate over
+// region set the above calculations would be greatly simplified and
-// time and, even though this is allowed according to the spec, it
+// be made more accurate.
-// broke several assumptions in the M&M framework (there were cases
+//
-// where used would reach a value greater than max). So, for max we
+// We update all the above synchronously and we store the results in
-// use -1, which means "undefined" according to the spec.
+// fields so that we just read said fields when needed. A subtle point
-//
+// is that all the above sizes need to be recalculated when the old
-// 4) Now, there is a very subtle issue with all the above. The
+// gen changes capacity (after a GC or after a humongous allocation)
-// framework will call get_memory_usage() on the three pools
+// but only the eden occupancy changes when a new eden region is
-// asynchronously. As a result, each call might get a different value
+// allocated. So, in the latter case we have minimal recalcuation to
-// for, say, survivor_num which will yield inconsistent values for
+// do which is important as we want to keep the eden region allocation
-// eden_used, survivor_used, and old_gen_used (as survivor_num is used
+// path as low-overhead as possible.
-// in the calculation of all three). This would normally be
-// ok. However, it's possible that this might cause the sum of
-// eden_used, survivor_used, and old_gen_used to go over the max heap
-// size and this seems to sometimes cause JConsole (and maybe other
-// clients) to get confused. There's not a really an easy / clean
-// solution to this problem, due to the asynchrounous nature of the
-// framework.
 class G1MonitoringSupport : public CHeapObj {
 G1CollectedHeap* _g1h;
-VirtualSpace* _g1_storage_addr;
 // jstat performance counters
 //  incremental collections both fully and partially young
 CollectorCounters*   _incremental_collection_counters;
 //  full stop-the-world collections
 CollectorCounters*   _full_collection_counters;
 //  young collection set counters.  The _eden_counters,
 // _from_counters, and _to_counters are associated with
 // this "generational" counter.
 GenerationCounters*  _young_collection_counters;
-//  non-young collection set counters. The _old_space_counters
+//  old collection set counters. The _old_space_counters
 // below are associated with this "generational" counter.
-GenerationCounters*  _non_young_collection_counters;
+GenerationCounters*  _old_collection_counters;
 // Counters for the capacity and used for
 //   the whole heap
 HSpaceCounters*      _old_space_counters;
 //   the young collection
 HSpaceCounters*      _eden_counters;
 //   the survivor collection (only one, _to_counters, is actively used)
 HSpaceCounters*      _from_counters;
 HSpaceCounters*      _to_counters;
+// When it's appropriate to recalculate the various sizes (at the
+// end of a GC, when a new eden region is allocated, etc.) we store
+// them here so that we can easily report them when needed and not
+// have to recalculate them every time.
+size_t _overall_reserved;
+size_t _overall_committed;
+size_t _overall_used;
+size_t _young_region_num;
+size_t _young_gen_committed;
+size_t _eden_committed;
+size_t _eden_used;
+size_t _survivor_committed;
+size_t _survivor_used;
+size_t _old_committed;
+size_t _old_used;
+G1CollectedHeap* g1h() { return _g1h; }
 // It returns x - y if x > y, 0 otherwise.
 // As described in the comment above, some of the inputs to the
 // calculations we have to do are obtained concurrently and hence
 // may be inconsistent with each other. So, this provides a
 } else {
 return 0;
 }
 }
+// Recalculate all the sizes.
+void recalculate_sizes();
+// Recalculate only what's necessary when a new eden region is allocated.
+void recalculate_eden_size();
 public:
-G1MonitoringSupport(G1CollectedHeap* g1h, VirtualSpace* g1_storage_addr);
+G1MonitoringSupport(G1CollectedHeap* g1h);
-G1CollectedHeap* g1h() { return _g1h; }
+// Unfortunately, the jstat tool assumes that no space has 0
-VirtualSpace* g1_storage_addr() { return _g1_storage_addr; }
+// capacity. In our case, given that each space is logical, it's
+// possible that no regions will be allocated to it, hence to have 0
-// Performance Counter accessors
+// capacity (e.g., if there are no survivor regions, the survivor
-void update_counters();
+// space has 0 capacity). The way we deal with this is to always pad
-void update_eden_counters();
+// each capacity value we report to jstat by a very small amount to
+// make sure that it's never zero. Given that we sometimes have to
+// report a capacity of a generation that contains several spaces
+// (e.g., young gen includes one eden, two survivor spaces), the
+// mult parameter is provided in order to adding the appropriate
+// padding multiple times so that the capacities add up correctly.
+static size_t pad_capacity(size_t size_bytes, size_t mult = 1) {
+return size_bytes + MinObjAlignmentInBytes * mult;
+}
+// Recalculate all the sizes from scratch and update all the jstat
+// counters accordingly.
+void update_sizes();
+// Recalculate only what's necessary when a new eden region is
+// allocated and update any jstat counters that need to be updated.
+void update_eden_size();
 CollectorCounters* incremental_collection_counters() {
 return _incremental_collection_counters;
 }
 CollectorCounters* full_collection_counters() {
 return _full_collection_counters;
 }
-GenerationCounters* non_young_collection_counters() {
+GenerationCounters* young_collection_counters() {
-return _non_young_collection_counters;
+return _young_collection_counters;
+}
+GenerationCounters* old_collection_counters() {
+return _old_collection_counters;
 }
 HSpaceCounters*      old_space_counters() { return _old_space_counters; }
 HSpaceCounters*      eden_counters() { return _eden_counters; }
 HSpaceCounters*      from_counters() { return _from_counters; }
 HSpaceCounters*      to_counters() { return _to_counters; }
 // Monitoring support used by
 //   MemoryService
 //   jstat counters
-size_t overall_committed();
-size_t overall_used();
+size_t overall_reserved()           { return _overall_reserved;     }
+size_t overall_committed()          { return _overall_committed;    }
-size_t eden_space_committed();
+size_t overall_used()               { return _overall_used;         }
-size_t eden_space_used();
+size_t young_gen_committed()        { return _young_gen_committed;  }
-size_t survivor_space_committed();
+size_t young_gen_max()              { return overall_reserved();    }
-size_t survivor_space_used();
+size_t eden_space_committed()       { return _eden_committed;       }
+size_t eden_space_used()            { return _eden_used;            }
-size_t old_space_committed();
+size_t survivor_space_committed()   { return _survivor_committed;   }
-size_t old_space_used();
+size_t survivor_space_used()        { return _survivor_used;        }
+size_t old_gen_committed()          { return old_space_committed(); }
+size_t old_gen_max()                { return overall_reserved();    }
+size_t old_space_committed()        { return _old_committed;        }
+size_t old_space_used()             { return _old_used;             }
+};
+class G1GenerationCounters: public GenerationCounters {
+protected:
+G1MonitoringSupport* _g1mm;
+public:
+G1GenerationCounters(G1MonitoringSupport* g1mm,
+const char* name, int ordinal, int spaces,
+size_t min_capacity, size_t max_capacity,
+size_t curr_capacity);
+};
+class G1YoungGenerationCounters: public G1GenerationCounters {
+public:
+G1YoungGenerationCounters(G1MonitoringSupport* g1mm, const char* name);
+virtual void update_all();
+};
+class G1OldGenerationCounters: public G1GenerationCounters {
+public:
+G1OldGenerationCounters(G1MonitoringSupport* g1mm, const char* name);
+virtual void update_all();
 };
 #endif // SHARE_VM_GC_IMPLEMENTATION_G1_G1MONITORINGSUPPORT_HPP

Mercurial > hg > graal-jvmci-8

comparison src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp @ 3980:8229bd737950