harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Date Thu, 26 Oct 2006 02:10:25 GMT
Ivan, agree. The multi-slot TLS allocation is only a superset that
keeps backward compatibility.

Btw, I was familiar with Linux TLS implementation (in Linuxthreads),
it was arranged into multiple-levels (like the inode blocks for a file
in filesystem). So the supported number of TLS keys can be large. I
haven't checked current TLS implementation (in NPTL), but I guess it
has no problem to support our demands. (Well, we can't guarantee how
native code in an application would use TLS, to be conservative is
safe anyway.)

Thanks,
xiaofeng

On 10/25/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> On 10/25/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> > Evgueni Brevnov wrote:
> > > Hi Guys,
> > >
> > > Just one little note from me... AFAIK Window and Linux have limitation
> > > on the number of TLS slots which can be allocated for any particular
> > > thread. I believe here is strong (probably performance) reasons for
> > > doing so. It can be a problem to implement arbitrary size TLS which
> > > seems to be required in case we want to allocate memory for keeping
> > > whole structures in it.
> >
> > Currently TM provides this service by using just *1* OS-level TLS slot.
> > The keys are allocated from a hythread_t structure:
> >
> > thread/src/thread_private.h
> >    166  typedef struct HyThread {
> >
> >    312      /**
> >    313       * Array representing thread local storage
> >    314       */
> >    315      void *thread_local_storage[10];
> >
> >
> > So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
>
> GCv5 may have different demand for the TLS data, but IMHO some of
> performance critical data can be made directly available in TLS and
> some less signicant may be accessed indirectly.
>
> --
> Ivan
> Intel Enterprise Solutions Software Division
>

Mime
View raw message