harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Date Wed, 13 Sep 2006 05:19:37 GMT
2006/9/13, Gregory Shimansky <gshimansky@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


Mime
View raw message