Re: [RFA] Skeletal JVMTI support

[Keith Seitz <keiths at redhat dot com>]

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