RFR: Shenandoah String Dedup refactoring

[Zhengyu Gu]

On 07/02/2018 05:16 PM, Roman Kennke wrote:
> 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

Ah, thanks to point out.

-Zhengyu

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