Low-Overhead Heap Profiling

[Jeremy Manson]

Hey Bernd,

In addition to the overhead of the mechanism (bad enough to implement
backpressure control?), I'd also be worried about losing thread-local state
in that case.  It would be hard to use TLS at the native layer to persist
data, or to map invocations to particular Java threads.

Also, you would have no guarantees about the callbacks being executed in a
timely fashion, or at all.

A user could set up a mechanism to do this themselves, if they wanted.  All
they would have to do is implement their own, purely native queue in the
callback mechanism.  Another thread could pull from the queue and use JNI /
Java to process the events.

In fact, we could provide an extension library to do this for them, if we
wanted, with the guidance "Use this particular callback, and you can
process the events in a Java thread".

Jeremy



On Wed, Jun 24, 2015 at 4:48 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150624/31d74b21/attachment.html>