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
