JEP 331: Low-Overhead Heap Profiling

[Aleksey Shipilev]

On 03/29/2018 07:12 PM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/331

Interesting JEP!

*) It would be nice to mention the implementation details in the JEP itself, i.e. where are the
points it injects into GCs to sample? I assume it has to inject into CollectedHeap::allocate_tlab,
and it has to cap the max TLAB sizes to get into allocation slowpath often enough?

*) Since JC apparently has the prototype, it would be easier to put it somewhere, and link it into
the JEP itself. Webrevs are interesting, but they get outdated pretty quickly, so maybe putting the
whole thing in JDK Sandbox [1] is the way to go.

Otherwise it leads to speculation, which raises the questions like below:

*) Motivation says: "The downsides [of JFR] are that a) it is tied to a particular allocation
implementation (TLABs), and misses allocations that don’t meet that pattern; b) it doesn’t allow the
user to customize the sampling rate; c) it only logs allocations, so you cannot distinguish between
live and dead objects."

 ...but then JEP apparently describes sampling the allocations via TLABs? So, the real difference is
(b), allowing to customize the sampling rate, or do I miss something?

*) Goals say: "Can give information about both live and dead Java objects."

 ...but there is not discussion what/how does it give information about the dead Java objects. I am
struggling to imagine how allocation sampling would give this. Is the goal too broad, or some API is
not described in the JEP?

Thanks,
-Aleksey

[1] http://cr.openjdk.java.net/~chegar/docs/sandbox.html