harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy" <pavel.reb...@gmail.com>
Subject Re: [drlvm] thread local storage in open/hythread.h
Date Mon, 31 Mar 2008 11:04:50 GMT
Nathan,

TLS access is a performance critical function, that why unified (single,
clean) approach could have 20-30% of performance degradation on some
benchmarks.

On 31/03/2008, Nathan Beyer <nbeyer@gmail.com> wrote:
>
> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> <gshimansky@apache.org> wrote:
> >
> > On 29 марта 2008 Nathan Beyer wrote:
> >  > In open/hythread.h there is the following bit of code.
> >  >
> >  > #ifdef PLATFORM_POSIX
> >  > extern __thread hythread_t tm_self_tls;
> >  > #else
> >  > extern __declspec(thread) hythread_t tm_self_tls;
> >  > #endif //PLATFORM_POSIX
> >  >
> >  >
> >  > hy_inline hythread_t VMCALL hythread_self() {
> >  >     return tm_self_tls;
> >  > }
> >  >
> >  > From what I know at the moment, the use of '__thread' isn't a POSIX
> >  > standard, but rather a gcc extension and '__declspec(thread)' is a
> >  > MSVC thing, so the check isn't quite correct. Neither of these works
> >  > on MacOS X and from what I've been able to gather, it shouldn't work
> >  > on FreeBSD, but I can't confirm that. In any case, I was looking at
> >  > implementing this for MacOSX and FreeBSD using pthread_key_t. It
> seems
> >  > like that could be used for other (all?) platforms as well. Any
> >  > thoughts on that?
> >
> >  AFAIK there are plenty of different implementation for getting TLS in
> DRLVM's
> >  implementation of hythread. There are fast ways like those you've
> mentioned,
> >  slow ways using APR and pthread and very fast ways using inline
> assembly.
> >
> >  All of them are quite messed up right now and need some cleaning. The
> mess is
> >  with different defines that rule the whole stuff - it is not always
> clear
> >  which define set is used for a particular implementation on a given
> platform.
>
>
> I would agree that the defines are a bit of a mess or at least seem
> like it at times.
>
> Do you have any suggestions or preferences about a particular TLS
> approach? I'm all for fast, but I tend to lean towards a consistent
> (single) clean approach, even it it's not the fastest approach.
>
> >
> >  --
> >  Gregory
> >
>



-- 
Best regards,
Pavel Rebriy
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message