harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Date Wed, 13 Sep 2006 03:39:28 GMT
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?

-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message