RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid)

Jie Fu jiefu at openjdk.java.net
Wed Oct 14 12:57:11 UTC 2020


On Wed, 14 Oct 2020 02:07:56 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi @kimbarrett ,
>> 
>> I replace __sync_val_compare_and_swap whith __atomic_compare_exchange and it really woks.
>> Thanks for your help.
>> 
>> I also fix the following bug when building zero VM on MacOS.
>> --------------------------------------------------------------
>>    * For target hotspot_variant-zero_libjvm_objs_os_bsd_zero.o:
>>    ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:176:21: error: no member named 'in_stack_yellow_reserved_zone' in
>>    'JavaThread'
>>            if (thread->in_stack_yellow_reserved_zone(addr)) {
>>                ~~~~~~  ^
>>    ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:177:19: error: no member named 'disable_stack_yellow_reserved_zone' in
>>    'JavaThread'
>>              thread->disable_stack_yellow_reserved_zone();
>>              ~~~~~~  ^
>>    ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:180:26: error: no member named 'in_stack_red_zone' in 'JavaThread'
>>            else if (thread->in_stack_red_zone(addr)) {
>>                     ~~~~~~  ^
>>    ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:181:19: error: no member named 'disable_stack_red_zone' in 'JavaThread'
>>              thread->disable_stack_red_zone();
>>              ~~~~~~  ^
>> --------------------------------------------------------------
>> 
>> Testing:
>>   - Zero VM builds on Linux/x64 with both clang and gcc
>>   - Zero VM build on MacOS
>> 
>> As for the memory ordering of the zero implementation, it might be better to file another bug to fix it.
>> What do you think?
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Thanks @kimbarrett for your review.
> I will spend some time to digest your comments on the memory model semantics.

Hi @kimbarrett ,

I agree with you.
All of the atomic operations that imply a read-modify-write action guarantee a two-way memory barrier across that
operation. So FULL_MEM_BARRIERs (before and after the atomic operation) should be added.

The patch has been updated.
Please review it.
Thanks.

Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/496


More information about the hotspot-runtime-dev mailing list