harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Date Wed, 13 Sep 2006 23:15:32 GMT
   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.


On 9/13/06, Weldon Washburn <weldonwjw@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.

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