harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Date Wed, 13 Sep 2006 11:12:42 GMT
On 9/13/06, Jimmy, Jing Lv <firepure@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
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