RFR(xs): 8213834: JVMTI ResourceExhausted should not be posted in CompilerThread

[Glyn Normington]

> Do you, by any chance, know more real-world examples of JVMTI agents
> subscribing to ResourceExhausted?

The agents which do this that I am aware of are:
* https://github.com/airlift/jvmkill
* https://github.com/cloudfoundry/jvmkill (forked from airlift/jvmkill)
* https://github.com/jolynch/jvmquake (inspired by airlift/jvmkill)

On Wed, Nov 21, 2018 at 3:23 PM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi Glyn,
>
> thank you for your input!
>
> On Wed, Nov 21, 2018 at 3:36 PM Glyn Normington <gnormington at pivotal.io>
> wrote:
> >
> > Another solution which I don't think has been considered in this thread
> > would be to give the resource exhaustion exit some way of determining
> > whether it is being driven on a compiler thread in which case the exit
> > could skip the analyses which run into the JVM internal error.
> >
>
> I think J.C. Beyler meant something like this in his afterthoughts to:
>
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031139.html
>
> "(A side note would be perhaps to augment ThreadInfo* with the
> "can_call_java" bit and then put in the right spots of the spec that only
> threads marked as "can_call_java" can safely call Java)."
>
> But unfortunately this only works for future releases, not retroactively.
>
> > I couldn't find a way to do this as the relevant header files are
> internal
> > to Hotspot and not exposed on JVMTI or JNI.
> >
> > As was mentioned earlier, there is more context in:
> > https://github.com/cloudfoundry/java-buildpack/issues/500 (which was
> closed
> > because we couldn't find a solution, in spite of a solution being very
> > desirable).
> >
> > Regards,
> > Glyn
>
> Do you, by any chance, know more real-world examples of JVMTI agents
> subscribing to ResourceExhausted?
>
> Cheers, Thomas
>


-- 
Regards,
Glyn