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

[Thomas Stüfe]

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