On 6/19/06, Graeme Johnson <[EMAIL PROTECTED]> wrote:
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.
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.
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
