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 (e...@zusammenkunft.net) wrote: Am Wed, 24 Jun 2015 16:26:35 -0700 schrieb Jeremy Manson <jeremyman...@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 tprinte...@twitter.com
