What actions are allowed in an JVMTI ResourceExhausted event handler?

[Thomas Stüfe]

On Wed, Nov 14, 2018, 06:32 David Holmes <david.holmes at oracle.com wrote:

> Hi Thomas,
>
> On 14/11/2018 6:50 am, Thomas Stüfe wrote:
> > Hi all,
> >
> > We have a client using CloudFoundry and its "jvmkill" agent. That is a
> > tiny JVMTI agent (see https://github.com/cloudfoundry/jvmkill) which
> > subscribes to the JVMTI ResourceExhausted Event. In the handler it
> > then does call JVMTI FollowReferences() to produce a heap histogram.
> >
> > The thing is, at our client we seem to run out of Metaspace in a
> > compiler thread. That thread normally would swallow the Metaspace OOM
> > and just bailout from the compilation. But as part of the metaspace
> > OOME handling the ResourceExhausted event gets posted, the handler
> > then uses JVMTI FollowReferences() and attempts to print out the heap
> > histogram, then runs into a guarantee since the compiler thread cannot
> > call java methods.
> >
> > My question is: are there any limitations about what one can do inside
> > a ResourceExhausted event handler?
>
> Not specified no. But the reality of JVM TI is that you can't anticipate
> every execution context and there are times when there are implicit
> constraints imposed by the implementation.
>
> In this case I think we have a mismatch between the fact we post the
> event from the compiler thread, but that a compiler thread is not a true
> "Java thread" and so can not execute arbitrary JNI or JVM TI code, or in
> particular can not lead to executing Java code. I think we should not be
> posting the event from the compiler thread in this case.
>
> Cheers,
> David
>

Hi David,

Yes I thought so too. I'll prepare a fix.

Thanks, Thomas


> > I checked the
> https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html
> > documentation, but I cannot find any mentioning of limitations in that
> > case.
> >
> > Thanks and Best Regards, Thomas
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181114/cbdefd39/attachment.html>