Concurrent heap monitoring

[Kemper, William]

The feature is independent from GCs, but it is aware of GC activity and it may be preempted by the GC at any time (which causes the loss of any work in progress). We have only tested it with G1, but we expect it to work with Parallel and Serial collectors. It is meant to stay out of the way of GC, but it is not yet aware of the concurrent phases of G1, Shenandoah and ZGC, so there is more work to be done here.


Thank you for the questions,

William


________________________________
From: Volker Simonis <volker.simonis at gmail.com>
Sent: Saturday, May 21, 2022 12:49 AM
To: Kemper, William
Cc: serviceability-dev
Subject: RE: [EXTERNAL]Concurrent heap monitoring


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


This sounds very interesting. Does this feature work with every GC or  does the implementation depend on specific GCs (and if the latter, which GCs does your prototype currently support).

Kemper, William <kemperw at amazon.com<mailto:kemperw at amazon.com>> schrieb am Fr., 20. Mai 2022, 23:46:

Taking a heap dump is a stop the world event. Garbage collection events can provide heap utilization information only after a cycle completes. We've found that detailed heap occupancy data (such as heap inspections provide) are too expensive to use for production monitoring.  Similarly, we find that heap statistics generated from collection cycles may come too late and may not provide enough detail (young collections do not reflect the state of the old generation). We have developed a prototype feature to provide detailed heap metrics concurrently, without barriers. It therefore provides only an estimate as changes to the object graph may cause it to miss objects. We would like to hear the thoughts of serviceability experts on such a thing. It is only at the proof of concept phase, but it is able to run popular benchmarks (specjbb, dacapo) with minimal overhead and the estimates are sufficiently accurate for our use cases (monitoring heap and object growth rates).


Thank you for reading,

William