Build broken on ARM32 since "8242088: Replace mutually exclusive lists with concurrent alternatives"

David Holmes david.holmes at oracle.com
Sat Jun 6 12:26:39 UTC 2020


<dropped build-dev>

It looks like 824088 introduced unconditional use of atomic operations 
on a non-pointer 64-bit value. Not all 32-bit platforms support 64-bit 
atomic operations. From atomic.hpp:

   // Atomic operations on int64 types are not available on all 32-bit
   // platforms. If atomic ops on int64 are defined here they must only
   // be used from code that verifies they are available at runtime and
   // can provide an alternative action if not - see supports_cx8() for
   // a means to test availability.

The JFR code that applies the atomic op needs to be guarded with

if (VM_Version::supports_cx8())
   <code using atomic>
else
   <alternative when atomics not available>

David

On 6/06/2020 9:56 am, Magnus Ihse Bursie wrote:
> On 2020-06-05 17:21, Marc Hoffmann wrote:
>> Dear JDK Build Team,
>>
>> it looks after "8242088: Replace mutually exclusive lists with 
>> concurrent alternatives” 
>> (http://hg.openjdk.java.net/jdk/jdk/rev/e51cdea8457e 
>> <http://hg.openjdk.java.net/jdk/jdk/rev/e51cdea8457e>) the build on 
>> arm32 is broken. The compiler error is:
>>
>> /workspace/build/linux-arm-server-release/hotspot/variant-server/libjvm/objs/jfrStorage.o: 
>> In function 
>> `JfrConcurrentLinkedListHost<JfrConcurrentQueue<JfrValueNode<JfrBuffer*>, 
>> JfrCHeapObj>, HeadNode, 
>> JfrCHeapObj>::remove(JfrValueNode<JfrBuffer*>*, 
>> JfrValueNode<JfrBuffer*> const*, JfrValueNode<JfrBuffer*>*, bool) 
>> [clone .constprop.212]':
>> jfrStorage.cpp:(.text+0x262): undefined reference to `unsigned long 
>> long Atomic::PlatformAdd<8u>::add_and_fetch<unsigned long long, 
>> unsigned long long>(unsigned long long volatile*, unsigned long long, 
>> atomic_memory_order) const'
>> /workspace/build/linux-arm-server-release/hotspot/variant-server/libjvm/objs/jfrStorage.o: 
>> In function `JfrConcurrentLinkedListHost<JfrConcurrentQueue<JfrBuffer, 
>> JfrCHeapObj>, HeadNode, JfrCHeapObj>::remove(JfrBuffer*, JfrBuffer 
>> const*, JfrBuffer*, bool)':
>> jfrStorage.cpp:(.text._ZN27JfrConcurrentLinkedListHostI18JfrConcurrentQueueI9JfrBuffer11JfrCHeapObjE8HeadNodeS2_E6removeEPS1_PKS1_S6_b[_ZN27JfrConcurrentLinkedListHostI18JfrConcurrentQueueI9JfrBuffer11JfrCHeapObjE8HeadNodeS2_E6removeEPS1_PKS1_S6_b]+0x2a4): 
>> undefined reference to `unsigned long long 
>> Atomic::PlatformAdd<8u>::add_and_fetch<unsigned long long, unsigned 
>> long long>(unsigned long long volatile*, unsigned long long, 
>> atomic_memory_order) const'
>> collect2: error: ld returned 1 exit status
>> lib/CompileJvm.gmk:149: recipe for target 
>> '/workspace/build/linux-arm-server-release/support/modules_libs/java.base/server/libjvm.so' 
>> failed
>> make[3]: *** 
>> [/workspace/build/linux-arm-server-release/support/modules_libs/java.base/server/libjvm.so] 
>> Error 1
>> make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed
>> make[2]: *** [hotspot-server-libs] Error 2
>>
>> Sorry for raising the issue on this list, but as an external person I 
>> is hard to identify the correct contacts.
> This is an issue not with the build system, but with the source code. 
> Take this on hotspot-jfr-dev. (cc:ed).
> 
> /Magnus
>>
>> Best regards,
>> -marc
> 


More information about the hotspot-jfr-dev mailing list