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

[JC Beyler]

For what it's worth I wonder if skipping the event is the best; it is the
easiest to ensure non breaking the agent; it does not really go against
what the spec is saying and another thread that CAN call java will most
likely hit the issue and then all will be good in the world.

However, also for what it's worth I wonder if deferring is not that hard to
accomplish either. There already is the infrastructure for this and we
should be relatively able to do it. Only question I would have is can the
service thread create a JNIEnv for the event but I don't think that's an
issue, is it?

It might however conflict with the description of the JNIEnv in the spec
which says the jni_env is "The JNI environment of the event (current)
thread" though it doesn't say current of what or the event thread of what
really.

However, skipping it also kind of goes against the spec since it says:
"Sent when a VM resource needed by a running application has been
exhausted".Though someone could argue it doesn' t say it is sent when the
resource was first noticed to be exhausted.

So, if I over-read the spec and look at options, it seems that:
- Sending the event via the compiler thread will risk breaking things if
the agent calls Java    -> not really an option
- Using the service thread breaks what David calls the synchronous
assumption of the event
- Skipping the event kind of breaks the sentence that the event is sent
when a VM resource has been exhausted

So we come back to probably skipping is the best solution since at least
the event remains "synchronous" when you get it.

(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).

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181114/2c8fee85/attachment.html>