2006/9/13, Gregory Shimansky <[EMAIL PROTECTED]>:
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.
The Thread.getContextClassLoader() just performs access restriction
checks and return the corresponding field value.
I think the only problematic function is ThreadGroup.enumerate() -
unless security access control is applicable to JVMTI agent requests
:).
--
Alexey
--
Gregory Shimansky, 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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
