Low-Overhead Heap Profiling

[Tony Printezis]

Bernd,

I like the idea of buffering up the sampled objects in, some data structure. But I assume it’d have to be a per-thread data structure to avoid conention issues. So, we’ll also need a periodic task that collects all such data structures and makes them available (somehow) to whoever wants to consume them?

Tony

On June 24, 2015 at 7:49:06 PM, Bernd Eckenfels (ecki at zusammenkunft.net) wrote:

Am Wed, 24 Jun 2015 16:26:35 -0700  
schrieb Jeremy Manson <jeremymanson at google.com>:  
> > As for the other concern: my concern about *just* having the  
> > callback mechanism is that there is quite a lot you can't do from  
> > user code during an allocation, because of lack of access to JNI.  
> >  
> >  
> > Maybe I missed something. Are the callbacks in Java? I.e., do you  
> > call them using JNI from the slow path you call directly from the  
> > allocation code?  
> >  
> > (For context: this referred to the hypothetical feature where we can  
> provide a callback that invokes some code from allocation.)  

What about a hypothetical queueing feature, so you can process the  
events asynchronously (perhaps with some backpressure control). This  
would work well for statistics processing.  

(Your other use case, the throwing of OOM would not work, I guess)  

But its an elegant solution to provide a code environment generic enoug  
for all kinds of instrumentation and independent of the "allocation  
recursion".  

Greetings  
Bernd  
-----

Tony Printezis | JVM/GC Engineer / VM Team | Twitter

@TonyPrintezis
tprintezis at twitter.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150625/95cb42ff/attachment.htm>