harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ronald Servant" <ronald.serv...@gmail.com>
Subject Re: [vmi] thread library
Date Tue, 30 Jan 2007 22:33:06 GMT
On 1/30/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> I've copied part of your JIRA comment over here for discussion.
> > One such issue would involve thread local storage (TLS). The Harmony
> > implementation of TLS uses static variables as the basis for its
> > implementation. Those statics are confined on a shared library basis.
> > Meaning that if a TLS value was being set when the VM called a thread
> > lib function, a call to a thread lib function from the classlib would
> > not see that TLS data. This is due to the VM and classlib using
> > different thread library shared libraries.
> Is this a problem in practice?  Can you think of a case where the VM and
> classlib exchange data through TLS like this?

MACRO_SELF() is the first example that jumps to mind.  It uses TLS
data to find a per thread data structure that is created by the VM
when a thread is created and can be referenced by the classlib when
its natives call into the thread library.  In this scenario using two
different shared libraries results in the per thread data structure
being stored in the TLS area that is only visible from the VM linked
thread library.  When the classlib comes to look  for it, the data is
structure is a null pointer.

> > The thread library used by the VM, for example, could be relying on
> > some storing values in TLS that will modify the behaviour of other
> > calls to thread library functions. When the classlib calls it's own
> > implementation of thread library functions, the behvaiour of those
> > functions will not be modified by the values set in TLS by the VM.
> Agreed, this says that a single, consistent threadlib is the answer --
> and as we have discussed elsewhere the VM needs some control (or at
> least oversight) of these calls for thread management etc.
> > A solution to these problems would be to create a standard thread API,
> > much like the one created for the port library.
> and the API is likely reduced from the threadlib functions we have in
> class library code today, to include just those that Salikh has listed.

Agreed, or perhaps a slightly larger set to accommodate tools that
might want to use threading.   The set I put in the patch is pretty
close the set that Salikh put together.

> > The VM would become responsible for providing the hythr shared library.
> > The classlib (and other tools that use threading functions) would
> > compile against the API and no-opt implementation of hythr.
> Or we could provide a working reference impl of the functions for VMs
> that don't care, and support testing the portlib without a VM present.

I don't have a problem with this, other than having someone
accidentally leave the shared library in a distribution that contains
a VM with a library of the same name.  We would either load the wrong
library or again have two libraries loaded (one by the VM and the
other by the classlib).

> > The attached patch is one possible implementation of this idea. It
> > creates a thread library table (HyThreadLibrary) much like the port
> > library table. The thread library is created by the port library during
> > the port library's initialization. The thread library can be obtained
> > from the port library using the new port_get_thread_library() function.
> I need to look at the patch to see how you did that, and also allow a VM
> to provide the impl.

In portlib/build.xml I removed the copy command that copies hythr.dll
over to the deploy tree.

> > Also, the VMI has been extended to include a new GetThreadLibrary()
> > function. Alternatively, we could leave the VMI as is and modify the
> > following defines in hythread.h to:
> > #define THREAD_ACCESS_FROM_VMI(vmi) HyPortLibrary *privatePortLibraryForThread =
(*vmi)->GetPortLibrary(vmi); \
> > HyThreadLibrary *privateThreadLibrary = privatePortLibraryForThread ->port_get_thread_library(privatePortLibraryForThread)
> >
> > THREAD_ACCESS_FROM_ENV and THREAD_ACCESS_FROM_JAVAVM would need to be modified in
a similar way.
> May as well modify the macros, I don't see a use for the
> GetThreadLibrary() function directly.

I will submit an updated patch that removes the VMI modifications and
updates the macros. Unless someone can see value in the VMI change.

J9 VM Development
IBM Ottawa Software Lab

View raw message