harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Johnson <Graeme_John...@ca.ibm.com>
Subject Re: [jchevm+classlibadapter] Running classlib tests
Date Mon, 19 Jun 2006 17:47:53 GMT
Archie Cobbs <archie@dellroad.org> 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 
> static native methods (Thread.internaAttach() and 
> 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 
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 
in your case?

Graeme Johnson
J9 VM Team, IBM Canada.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message