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 <[EMAIL PROTECTED]> wrote:
On 10/25/06, Salikh Zakirov <[EMAIL PROTECTED]> 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
