CNI invocation API proposal

Fri Apr 13 10:43:00 GMT 2001

On 2001年4月13日, [iso-8859-1] Joerg Brunsmann wrote:
> 1. Do we need to attach/detach threads to the GCJ JVM?

I think so. Java threads are native threads with a java.lang.Thread peer.
For now the only way to get a Java thread is to create a new one; there is
no means to bind an existing native thread to the gcj runtime.
That means the primordial thread can never execute Java code.
Currently the primordial thread does nothing but wait for all the
non-daemon threads to terminate.
The ugly part of JNI is that it allows a thread to detach from a different
stack frame than it attached from. If a thread detaches prematurely, any
locks it holds must somehow be released.
To avoid that I would prefer not to have both attach and detach methods,
but rather a single method that will register the calling thread, execute
a callback function, then unregister itself, similar to what JvRunMain
does now (but without spawning a new thread).
A question is whether the GC should be aware of non-Java threads. IMO the
answer is no. There are applications like web servers in which the
majority of threads may have nothing to do with a VM, and it would be
unnecessary to suspend/resume these or mark their stacks.
Implementing this properly would require some new hooks into the GC's
pthread interface.
> 2. Do we need to destroy a GCJ JVM?

Perhaps not, since there can only be one active VM. If destroy is a null
operation, no resources (heap memory) will be freed. But all resources
are released on exit() anyway.
Is it very likely that programs would often want to destroy a VM without
terminating themselves?
> 3. Is it possible and reasonable to build a JNI based 
> invocation interface upon the CNI based approach?

I think so, provided you can safely implement attach/detach and
dynamically load the VM (i.e. dlload libgcj.so).
> 4. Two non-java processes p1 and p2 with two threads
> each, say t11, t12, t21 and t22 which use a statically 
> linked gcj object engine. Each process p1 and p2 has its 
> own reference to the gcj object engine because of static
> linkage. Assume now that the non-java processes p1 
> and p2 with their threads use a dynamic linkage scheme. 
> Now two different processes use the same gcj object engine
> where for example t22 and t11 concurrently use the GCJ JVM.
> Does this make sense? Does this cause problems?

Two processes will each get their own VM regardless of how they bind to
the runtime. The reason is that data sections in a shared library are not
shared across processes. (There are some historical exceptions, notably
Win16. Do any of these still matter?)
Jeff