RFR: Shenandoah String Dedup refactoring

[Roman Kennke]

Am 02.07.2018 um 23:02 schrieb Zhengyu Gu:
> 
> 
> On 07/02/2018 04:44 PM, Roman Kennke wrote:
>> Is it really necessary to use global locks? Is there no instance that
>> can 'carry' the lock? I guess it's not a Shenandoah specific lock
>> though, right? IOW, similar issue as with SATB locks..?
> 
> I assume you are talking about StringDedupQueue_lock and
> StringDedupTable_lock, right?
> 
> We adapted upstream's implementation, so yes, it is similar to SATB
> locks, we do need them too.

ok.


>> Thread-local is not a language feature, yet. Coming with c++11. I
>> believe it's ok to put in ShenandoahThreadLocalData as long as we don't
>> need to extend its size. We should have some room left because of ZGC
>> :-) Should we ever switch to C++11 we'd use real thread_local though, I
>> guess.
>>
> 
> Kind of wonder where are we, in term of C++ version.

C++98:

$ grep -R "\-std" make/*
make/autoconf/flags-cflags.m4:    CXXSTD_CXXFLAG="-std=gnu++98"

I think this should be one of the next major OpenJDK goals to go
straight to c++17 or so.

> ZGC already uses
> it. I asked Thomas Schatzl what's they takes on thread-local, he did not
> answer :-)

Hmm, no. ZGC uses:

static __thread

which is, a GCC-ism:
https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html

C++ (>=11) thread-locals use the thread_local keyword:
https://en.cppreference.com/w/cpp/language/storage_duration

Cheers, Roman