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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
