Hi William,
How does this proposal interact with JVM/TI or with:
JEP 331: Low-Overhead Heap Profiling
http://openjdk.java.net/jeps/331
JDK-8171119 JEP 331: Low-Overhead Heap Profiling
https://bugs.openjdk.java.net/browse/JDK-8171119
JDK-8203394 Implementation of JEP 331: Low-Overhead Heap Profiling
https://bugs.openjdk.java.net/browse/JDK-8203394
Dan
On 5/27/22 6:12 PM, Kemper, William wrote:
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.simo...@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 <kemp...@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
