14.09.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а):
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
