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(
((hythread_library_t)GLOBAL_DATA(default_library))->self_ptr))

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
way.

> >> > 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.

Ron.
-- 
J9 VM Development
IBM Ottawa Software Lab

Mime
View raw message