Currently to maintain the proper ordering of load and unload events,
when you post
a compiled_method_load event, if there are pending
compiled_method_unload events,
then we "lock" the nmethod to ensure that the nmethod is not flushed
or unloaded while posting the event. What if we did that until the
compiled_method_load
event finished posting?
thanks,
Karen
On 01/25/11 14:00, Tom Rodriguez wrote:
On Jan 25, 2011, at 8:49 AM, Keith McGuigan wrote:
Hello,
This code modifies the way that JVMTI compiled-method-load events are posted. Previously, they were posted directly from the compiler thread, which could cause issues if the JVMTI event handling code made calls to RedefineClasses, since the compiler thread is unable to load classes if that is required. This solution is to defer the posting of the events to the Service thread (formerly: LowMemoryDetector
thread) which is a Java thread and is able to load classes.
The posting appears to be asynchronous which I don't think will work. The
method could be unloaded or invalidated and freed before the event has been
posted. It has to be done synchronously I think.
I have a vague memory of someone saying that there were restrictions on what a
JVMTI client was allowed to do in response to a CompiledMethodLoad but I can't
find any evidence of that. So is that just a bogus memory or is there some
restriction like this?
tom
The "Service thread" now handles both low-memory detection and JVMTI deferred
event posting. I left the door open for other types of events to be deferred and posted
via this mechanism in case we find other situations where posting events from a non-Java
thread causes problems.
webrev: http://cr.openjdk.java.net/~kamg/6766644/webrev.01/
--
- Keith
