You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Gregory Shimansky <gs...@gmail.com> on 2006/09/13 00:44:57 UTC
[drlvm] [jvmti] Question about JVMTI calling Java code
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.
--
Gregory Shimansky, 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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 14 September 2006 09:15 Alexey Varlamov wrote:
> > A more problematic data in my view may be something like
> > Thread.getContextClassLoader(). Since it is not directly needed for
> > threading model it isn't probably kept in any native structures. Getting
> > it may be done through direct access to the field of j/l/Thread. It is a
> > kernel class of course, but this will oblige a classlib implementation
> > for Harmony to have the same field name.
>
> I definitely miss smth here. The kernel class by definition is VM
> specific, the same as JVMTI implementation, what classlib
> implementation do you mean and what obligations?
> I believe we can get any of the attributes you listed via direct field
> access without imposing any dependencies (outside the VM).
Yes you are right here. This is a kernel class and VM can access its fields
without publishing it in any interfaces.
--
Gregory Shimansky, 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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Alexey Varlamov <al...@gmail.com>.
14.09.06, Gregory Shimansky<gs...@gmail.com> написал(а):
> On Wednesday 13 September 2006 16:14 Weldon Washburn wrote:
> > 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.
>
> This is what I am trying to determine. Just how much of the data currently
> _cannot_ be taken from the native code. I am quite sure thread manager can
> provide a thread name or its priority.
>
> A more problematic data in my view may be something like
> Thread.getContextClassLoader(). Since it is not directly needed for threading
> model it isn't probably kept in any native structures. Getting it may be done
> through direct access to the field of j/l/Thread. It is a kernel class of
> course, but this will oblige a classlib implementation for Harmony to have
> the same field name.
I definitely miss smth here. The kernel class by definition is VM
specific, the same as JVMTI implementation, what classlib
implementation do you mean and what obligations?
I believe we can get any of the attributes you listed via direct field
access without imposing any dependencies (outside the VM).
--
Alexey
> --
> Gregory Shimansky, 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
>
>
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 13 September 2006 16:14 Weldon Washburn wrote:
> 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.
This is what I am trying to determine. Just how much of the data currently
_cannot_ be taken from the native code. I am quite sure thread manager can
provide a thread name or its priority.
A more problematic data in my view may be something like
Thread.getContextClassLoader(). Since it is not directly needed for threading
model it isn't probably kept in any native structures. Getting it may be done
through direct access to the field of j/l/Thread. It is a kernel class of
course, but this will oblige a classlib implementation for Harmony to have
the same field name.
--
Gregory Shimansky, 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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Rana Dasgupta wrote:
> Weldon,
> It may be a little early to guard for architectural impact of large parts
> of the VM being written in Java? I don't think that we are quite there yet
> or need to consciously design to enable this till we have completed the
> MMTk
> integration and done exhaustive perf work.
I dunno. I wouldn't think we'd be doing for MMTk specifically, as
that's unproven for production use (although it would be excellent to
support it as an option for research work.
But in general, shouldn't week keep migration to a Java based VM in mind?
> In addition to the more trivial thread related data being accessible
> from C, to support ThreadGroup.Enumerate() etc. functions do we want a lot
> of additional state in the thread manager for this? It may have been
> nice to
> be able to add some recursion detection/protection support to the JVMTI
> implementation, if not necessarily turning off events on all Java code. I
> think that some level of recursion protection in JVMTI or in JVMTI based
> agents is not uncommon.
>
> Thanks,
> Rana
>
> On 9/13/06, Weldon Washburn <we...@gmail.com> wrote:
>>
>> >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.
>>
>>
>>
>
---------------------------------------------------------------------
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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Rana Dasgupta <rd...@gmail.com>.
Weldon,
It may be a little early to guard for architectural impact of large parts
of the VM being written in Java? I don't think that we are quite there yet
or need to consciously design to enable this till we have completed the MMTk
integration and done exhaustive perf work.
In addition to the more trivial thread related data being accessible
from C, to support ThreadGroup.Enumerate() etc. functions do we want a lot
of additional state in the thread manager for this? It may have been nice to
be able to add some recursion detection/protection support to the JVMTI
implementation, if not necessarily turning off events on all Java code. I
think that some level of recursion protection in JVMTI or in JVMTI based
agents is not uncommon.
Thanks,
Rana
On 9/13/06, Weldon Washburn <we...@gmail.com> wrote:
>
> >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.
>
>
>
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Weldon Washburn <we...@gmail.com>.
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....@gmail.com> wrote:
>
> On 9/13/06, Jimmy, Jing Lv <fi...@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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/13/06, Jimmy, Jing Lv <fi...@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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Thursday 14 September 2006 09:29 Geir Magnusson Jr. wrote:
>> Gregory Shimansky wrote:
>>> Actually this problematic function is used only in GetThreadGroupChildren
>>> for the information about threads and thread groups contained inside of
>>> this thread group. If this information is available from thread manager
>>> directly I would very much like to know how to get it. Looking at the
>>> current GetThreadGroupChildren implementation makes me very upset, it is
>>> clearly not meant for real usage.
>> Don't get upset. It will be ok. :)
>
> I hope so. This function definitely needs to be rewritten starting with
> NewObjectArray(10, ...) which allocates exactly 10 (not more) thread group
> children elements :)
Thanks for volunteering :)
geir
>
---------------------------------------------------------------------
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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 14 September 2006 09:29 Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
> > Actually this problematic function is used only in GetThreadGroupChildren
> > for the information about threads and thread groups contained inside of
> > this thread group. If this information is available from thread manager
> > directly I would very much like to know how to get it. Looking at the
> > current GetThreadGroupChildren implementation makes me very upset, it is
> > clearly not meant for real usage.
>
> Don't get upset. It will be ok. :)
I hope so. This function definitely needs to be rewritten starting with
NewObjectArray(10, ...) which allocates exactly 10 (not more) thread group
children elements :)
--
Gregory Shimansky, 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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Wednesday 13 September 2006 09:19 Alexey Varlamov wrote:
>> 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
>>
>> :).
>
> Actually this problematic function is used only in GetThreadGroupChildren for
> the information about threads and thread groups contained inside of this
> thread group. If this information is available from thread manager directly I
> would very much like to know how to get it. Looking at the current
> GetThreadGroupChildren implementation makes me very upset, it is clearly not
> meant for real usage.
Don't get upset. It will be ok. :)
geir
---------------------------------------------------------------------
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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 13 September 2006 09:19 Alexey Varlamov wrote:
> 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
>
> :).
Actually this problematic function is used only in GetThreadGroupChildren for
the information about threads and thread groups contained inside of this
thread group. If this information is available from thread manager directly I
would very much like to know how to get it. Looking at the current
GetThreadGroupChildren implementation makes me very upset, it is clearly not
meant for real usage.
--
Gregory Shimansky, 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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/13, Gregory Shimansky <gs...@gmail.com>:
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
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
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Posted by Rana Dasgupta <rd...@gmail.com>.
It might be OK to disable the event notification on loopback for these
thread/threadgroup java methods only? Would the misses of notification for
such methods in CompiledMethodLoad be a major issue?
Thanks,
Rana