Concurrent heap monitoring

[daniel.daugherty at oracle.com]

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.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> 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
>