[RFA] Skeletal JVMTI support
Keith Seitz
keiths@redhat.com
Thu Jul 20 18:00:00 GMT 2006
Tom Tromey wrote:
> Keith> +_Jv_JVMTIEnv *
> Keith> +_Jv_GetJVMTIEnv (void)
> Keith> +{
> Keith> + _Jv_JVMTIEnv *env
> Keith> + = (_Jv_JVMTIEnv *) _Jv_MallocUnchecked (sizeof (_Jv_JVMTIEnv));
> Keith> + env->p = &_Jv_JVMTI_Interface;
> Keith> + return env;
>
> We want to make a new one each time?
> (I know zero about jvmti, this just seemed a little odd.)
I don't know much about JVMTI in practice, either. Originally, I had
only one. But then I changed it after re-reading these passages from the
spec:
o "Each call to GetEnv creates a new JVM TI connection and thus a new
JVM TI environment."
o Each environment has its own state (for example, desired events, event
handling functions, and capabilities).
o Thus, unlike JNI which has one environment per thread, JVM TI
environments work across threads and are created dynamically.
There is also the JVMTI call DisposeEnvironment:
"jvmtiError
DisposeEnvironment(jvmtiEnv* env)
"Shutdown a JVM TI connection created with JNI GetEnv (see
Environments). Dispose of any resources held by the environment.
Suspended threads are not resumed, this must be done explicitly by the
agent. Allocated memory is not released, this must be done explicitly by
the agent. This environment may not be used after this call. This call
returns to the caller."
So I guess I should have added the DisposeEnvironment call to run the
gamut of creating/destroying environments.
Like all the Java specs, it's a little vague. Right now, it won't make a
difference, but if we are to fully implement the event callbacks, we'll
need jvmtiEnv to contain structures to hold state information for the
particular agent. I hope not to have to do that just yet. :-)
What would you like me to do?
Keith
More information about the Java-patches
mailing list