harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Date Wed, 13 Sep 2006 12:14:14 GMT
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 <a.y.chernyshev@gmail.com> wrote:
>
> 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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message