Archie Cobbs <[EMAIL PROTECTED]> wrote on 06/19/2006 10:16:42 AM: > Ivan Volosyuk wrote: > > As far as I can see classlib uses port library libprt.so which is > > intended to be used by VM as low level layer above OS threading > > system. Some kind of abstraction of underlying OS primitives. The port > > library is widely used in classlib. The port library data is > > accessible via TLS (it is done imho to support multi VM environments). > > To initialize each thread's TLS pointer to the port library the > > thread_attach() function is needed. > > We could handle this in the following manner: let's define two well-known > static native methods (Thread.internaAttach() and Thread.internalDetach()). > Then, if these exist, the VM will invoke them from within each thread at > the beginning and ending of its lifetime. > > This would require a simple change to the classlib code and any classlib > VM's. However, it would be a good change, because it would be making > explicit a VM-classlib dependency that is now implicit. > > Thoughts on this approach?
Ivan's description of the libraries is accurate. The port library (libhyprt.so) provides an abstraction of the underlying OS, and is built on top of the threading library (libhythr.so). The port library uses TLS for per-thread error code/message translation, and monitors to protect data structures in the NLS components. As Tim Ellison indicated hythread_attach() must be called by each thread that uses thread library functionality. The hythread_attach() does one-time initialization of per-thread state, and must be cleaned up by a corresponding call to hythread_detach(). Logically the VM's implementation of the JNI Invocation API has the most accurate knowledge of when a thread needs to be attached/detached. Logically, hythread_attach() should occur in the implementation of the JNI AttachCurrentThread() function, with the corresponding teardown occurring in DetachCurrentThread(). You want these calls to occur as early as possible so that the thread is free to make port and thread library calls. Putting the initialization into Java code leaves a potentially large window between the thread starting to run and the initialization happening. You might have more success using (or adding) an event reporting callback. The JVMTI thread start/end events should be fired at right point to do the attach/detach. Is using / piggy-backing on JVMTI event reporting an option in your case? Graeme Johnson J9 VM Team, IBM Canada.
