Re: CNI invocation API proposal

[Cedric Berger <cedric at wireless-networks dot com>]

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:

CallVoidMethod() {
    JavaPeer peer = getPeerOneWayOrAnother();
    if(peer.stackBottom == 0)
        peer.stackBottom = currentStack;
    reallyCallJavaMethod();
}

Cedric