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

[JC Beyler]

Hi Thomas,

On Mon, Nov 19, 2018 at 4:00 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi all,
>
> David and JC already outlined the options we have nicely.
>
> I'd like to add that I do not favor the ServiceThread delayed
> deliverance since a common reaction to ResourceExhausted would to
> print call stack of the thread running into it or to print a heap
> histogram, as jvmkill does. For the former only a synchronous event
> delivery makes sense, for the latter at least it helps analyzing.
>
> In cloud foundry, the heap histogram produced by the JVMTI agent can
> be helpful, and since in the majority of cases do not entail the
> compiler thread running out of metaspace, I'd rather preserve this
> ability. So to me, masking this event for this one case is the most
> pragmatic approach.
>
> The other option would be not to change the code but to add, in the
> JVMTI documentation for ResourceExhausted, the same disclaimer as for
> ObjectFree, GCStarted etc: "The event handler must not use JNI
> functions and must not use JVM TI functions except those which
> specifically allow such use". Then, writers of JVMTI agents like
> jvmkill would have to update their agents accordingly.
>
>


> FWIW, I think JCs idea of exposing the can_call_java attribute somehow
> to the outside would also work. But unfortunately not retroactively,
> for older releases. Whereas a simple internal patch like "mask
> ResourceExhausted" could be backported easily to older releases.
>
>
I actually agree with not using the service thread to be honest, resource
exhaustion seems to be something you'd want to know sooner than later.

How about we do both?
  - Fix it now so that the compiler thread does not post the event because
we'd rather not have crashes and that can get backported
  - Put out a RFE that would add the information to ThreadInfo and work
through the process of a CSR/etc. to get it working for future versions?

Thanks,
Jc



> Best Regards, Thomas
>
>
> On Thu, Nov 15, 2018 at 5:32 AM JC Beyler <jcbeyler at google.com> wrote:
> >
> > 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
>


-- 

Thanks,
Jc