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 <[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.
