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 Wed, 31 Jan 2007 14:54:52 GMT
On 1/31/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Ronald Servant wrote:
> > On 1/30/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >> 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.
> Maybe I'm being dumb, but I don't see it used by the class library code
> anywhere?  Can you point me to it.

The definition of MACRO_SELF() for reference is:
#define MACRO_SELF() ((hythread_t)TLS_GET(

Many of the existing thread library functions use MACRO_SELF(), such
as hythread_attach(), hythread_self(), hythread_monitor_self(), etc...

The classlib uses these hythread functions and as a side effect of the
current implementation uses TLS to pass information that is set by the
VM into code that is used by the classlib.

> > 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.
> Understood, and if there are examples of shared data being passed back
> and forth between the class library and VM via TLS, then that is a part
> of the VMI we haven't properly described.  I'm struggling to find such
> an example though.
> If there is no such shared data, then having the VM's TLS and classlib's
> TLS in these 'separate worlds' is no harm .

Upon closer inspection of the implementation the TLS I was referring
to (via MACRO_SELF)  is NOT the same TLS as that provided by
hythread_get_tls(), etc...

So as Angela points out, as long as there is no classlib code using
this hythread_xx_tls() functions directly than it doesn't matter that
there is only a single copy from a single shared library.

> >> 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).
> Isn't that just as likely as having the stub version left in by mistake?
> though I hope the stubs would fail earlier and be more obvious :-)

The stub version fails on startup, and we could likely add an error
message saying it is the stub version.  But again, I don't mind either

> >> > 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.
> Ah, the same way that we are doing the VMI library today.  In fact, why
> not just make those thread functions part of the same VMI DLL, then
> there is only one stub replacement required?

Hmmm... seems like a good idea, but we need to have the portlib link
against a shared library named hythr, so that at runtime it can in
fact find the real one provided by VM, or I am missing something
obvious?  or perhaps we get rid of the name hythr and put those
functions in vmi as well?  doesn't seem as clean to me.

J9 VM Development
IBM Ottawa Software Lab

View raw message