Low-Overhead Heap Profiling

Tony Printezis tprintezis at twitter.com
Thu Jun 25 20:55:43 UTC 2015


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?


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  


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

tprintezis at twitter.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150625/95cb42ff/attachment.html>

More information about the serviceability-dev mailing list