Gregory, You might want to look closely at the code paths in the JVMTI functions. If the functions in question happen to be arbitrary Java code, then these code paths could lead to many other parts of the JVM which in turn might be written in Java. In the future the JIT runtime helpers or the GC may be written in Java. For example, an innocent looking object new, poll for GC or poll for preemption inside a JVMTI function could take the execution path deep inside of MMTk, or as mentioned below, deep inside java.util.concurrent .
Rather than develop a general solution at this point, it may make sense to make all the data JVMTI needs to read/write accessible from C code. On 9/13/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
On 9/13/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote: > Gregory Shimansky wrote: > > Hello > > > > I have recently identified a problem which may potentially lead to an infinite > > recursion with the current implementation of some JVMTI functions in DRLVM. > > The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like > > Thread.getName() to return the necessary information to the JVMTI agent. > > > > This works ok in most cases but in case an agent chooses to call such methods > > from inside of events like MethodEntry, MethodExit, SingleStep, Breakpoint, > > etc for the exact Java methods like Thread.getName() this may easily lead to > > an infinite recursion. > > > > For the current DRLVM Thread Manager implementation it doesn't seem to be > > possible to get all of the information about Thread or ThreadGroup from > > native code only, so it is necessary to call Java anyway and I see only one > > solution which may not be perfect. > > > > It is possible to create a thread local flag for JVMTI which will disable > > sending any events to the loaded agents while calling Java code from inside > > of JVMTI API functions. This may impact the results of profiler agents and > > potentially miss some methods in CompiledMethodLoad event for tools like > > VTune, ThreadChecker and other. > > > > So I am unsure whether this fix is necessary or should we change threading > > code to make it possible to provide all necessary information in the native. > > The currently called Java Methods are > > > > Thread.getName() > > Thread.getPriority() > > Thread.isDaemon() > > Thread.getThreadGroup() > > Thread.getContextClassLoader() > > Thread.setDaemon() > > > > ThreadGroup.getParent() > > ThreadGroup.getName() > > ThreadGroup.getMaxPriority() > > ThreadGroup.isDaemon() > > ThreadGroup.enumerate() > > > > Quite a lot of these functions return information which is available from > > native code, but functions like Thread.getContextClassLoader() require > > calling Java. > > > > IIRC, the class Thread(and ThreadGroup) itself is a kernel class, isn't > it? It may be easier to get a inner field(e.g, thread name) than > invoking a method. > I don't know DRLVM well, However I doubt if JVMTI and kernel class are > together there in VM, it may be a clear and easy way to know each other? To get specifically the name of the thread, it is true that one can read directly the "name" field of the j.l.Thread without calling getName() method. There could be also more complex cases like ThreadGroup.enumerate() where the code won't be like reading the specific field. Also, getting the field contained in the structure (in our case - j.l.Thread) through the accessor method is more clean way compared to reading it directly. In the current implementation, JVMTI code doesn't depend on the internal representation of j.l.Thread, which can also be good thing. I wouldn't assume that JVMTI functions should never be calling Java code, because there is always a possibility that some parts of the JVM itself are written in Java. For example, I could imagine Java monitors implementation written in Java code with help of j.u.concurrent locks, in this case all the monitor data and associated debugging info/logic (like getOwnedMonitorInfo) would reside in the Java space. Thanks, Andrey. > > -- > > Best Regards! > > Jimmy, Jing Lv > China Software Development Lab, IBM > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Andrey Chernyshev Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
