harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [jchevm+classlibadapter] Running classlib tests
Date Mon, 19 Jun 2006 20:59:50 GMT
On 6/19/06, Graeme Johnson <Graeme_Johnson@ca.ibm.com> wrote:
> 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
> 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.

Very interesting idea.
Let me summarise my knowledge:
- Classlib requires thread_attach() to be called before calling some
of classlib java code (as the native implementation may rely on
specific thread's TLS state)
- jchevm (and number of other VM tied to classpath) know nothing about
classlib's port library - libprt.so
- there is a glue layer - classlibadapter which works as a bridge
between classpath-bound VMs (e.g. jchevm) and classlib.

So, you suggests, to implement in classlibadapter a JVMTI agent which
will handle thread attach JVMTI events? This could be a solution for
every JVMTI-aware VM. Unfortunately, AFAIK, jchevm doesn't support
JVMTI, and I am don't have the information about the support in other
classpath-bound VMs.

IMHO, Archie's suggestion is simplier and less intrusive, as the
function Thread.attachInternal() can be native function implemented in
classlibadapter itself.

Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message