CNI invocation API proposal
Fri Apr 13 12:14:00 GMT 2001
Jeff Sturm wrote:
> On Fri, 13 Apr 2001, Cedric Berger wrote:
> > > 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).
> > Oops, this would be very, very expensive.
> > 2 years ago, I was working on an application where I had:
> > - a C library with a public API, which allowed you to register callbacks
> > on status change (very much like add/remove listeners in java)
> > - theses callbacks where called from a thread initialized by the C library.
> > something like:
> > lib_add_statuschange_handler(my_handler)
> > lib_remove_statuschange_handler(my_handler)
> > then my_handler would be called by some thread, say 1000 times per second.
> In that case it would be helpful to have that thread created by the VM, so
> it has no need to attach.
If you can/will modify the library API.
> What are the alternatives? Hook
> into GC_pthread_create so every thread is attached from the very
> beginning? That assumes GC is linked into the executable, which may not
> be the case, particularly for JNI.
> Attaching an arbitrary thread from anywhere doesn't seem so easy to me.
> How would the GC find its stack bottom?
What I'm gonna say is maybee stupid, but:
Does the GC really need to know the stack bottom?
What I mean is that there should be *no* java object on the
stack before a thread enters the VM when it executes it's
first call to a java object, right?
the GC should only need to scan the stack of a thread from
this point to the top:
I.E: JNI/CNI:CallVoidMethod could be implemented this way:
JavaPeer peer = getPeerOneWayOrAnother();
if(peer.stackBottom == 0)
peer.stackBottom = currentStack;
More information about the Java