RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
kim.barrett at oracle.com
Wed Sep 11 23:34:36 UTC 2019
> On Sep 11, 2019, at 6:58 PM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Per,
> So if I read this right, the renaming will cause the C++11 thread_local to be used always on Windows (due to our use of VS 2017) but for Solaris Studio and gcc it will only be enabled if we explicitly ask for C++11 support - is that right?
> I see Windows Visual Studio and Solaris Studio clearly state the equivalence of the two mechanisms. I'm expecting gcc is the same, but I don't see that clearly stated.
Well, bleh! Thanks for making me look into that...
The release notes for gcc4.8  (where thread_local support was added)
describes an important performance difference between thread_local and
__thread, and mentions a compiler option to remove that difference under
some circumstances. It also suggests that because of this, one may want to
stick with __thread where it's still applicable. (An initializer for a
__thread variable must be a constant expression. )
The gcc9.2 manual  (latest) describes the relevant option
(-fno-extern-tls-init). Maybe we can use that, but it puts some non-standard
(and well hidden) restrictions on our use of thread_local, which somewhat
defeats the point.
Retracting my "Looks good”. Fooey!
More information about the hotspot-dev