8315884: New Object to ObjectMonitor mapping causes linux-aarch64 musl to fail

Tue Aug 20 05:39:10 UTC 2024

Hi all

Recently we at JetBrains became getting the following build failure for Linux aarch64 musl

===============================8<-------------------------------
. . .
Compiling up to 55 files for jdk.jpackage
/mnt/agent/work/f25b6e4d8156543c/src/hotspot/share/runtime/synchronizer.cpp: In static member function 'static intptr_t ObjectSynchronizer::FastHashCode(Thread*, oop)':
/mnt/agent/work/f25b6e4d8156543c/src/hotspot/share/runtime/synchronizer.cpp:1116:1: error: unable to generate reloads for:
1116 | }
| ^
(insn 565 564 566 28 (set (reg/v:DI 2 x2 [ reg2 ])
(ior:DI (and:DI (ashift:DI (reg/v:DI 188 [ <retval> ])
(const_int 8 [0x8]))
(const_int 549755813632 [0x7fffffff00]))
(and:DI (reg/v:DI 1 x1 [ reg1 ])
(const_int -549755813633 [0xffffff80000000ff])))) "/mnt/agent/work/f25b6e4d8156543c/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp":49:21 792 {*aarch64_bfidi5_shift_alt}
(nil))
during RTL pass: reload
/mnt/agent/work/f25b6e4d8156543c/src/hotspot/share/runtime/synchronizer.cpp:1116:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3962
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [lib/CompileJvm.gmk:168: /mnt/agent/work/f25b6e4d8156543c/build/linux-aarch64-server-release/hotspot/variant-server/libjvm/objs/synchronizer.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:245: hotspot-server-libs] Error 2
. . .
===============================8<———————————————

Note Linux x86_64 musl is successful.

After reverting the following changes, the aarch64 build becomes successful
 - 8337987: Relocate jfr and throw_exception stubs from StubGenerator to SharedRuntime (https://github.com/openjdk/jdk/commit/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60)
 - 8315884: New Object to ObjectMonitor mapping (https://github.com/openjdk/jdk/commit/bd4160cea8b6b0fcf0507199ed76a12f5d0aaba9)

Building for aarch64 is started within a docker containers.
Image of this container may be found at
-  https://hub.docker.com/layers/jetbrains/runtime/jbr21env_musl_aarch64/images/sha256-ef9a642934f04ec50598b3f920e468d5dc01a5691f7693b34a4e37e5d25c4658 

The docker file may be found here:
- https://github.com/JetBrains/JetBrainsRuntime/blob/main/jb/project/docker/Dockerfile.musl_aarch64

The container is being started on Ubuntu 22.04 aarch64

Just in case x86_64 is also started within a docker container. Its image and docker file
- https://hub.docker.com/layers/jetbrains/runtime/jbr21env_musl_x64/images/sha256-4d7b86ba4fa367c4a0613219bd997365f6b794091df902f16e24f06f9fd45a86 
- https://github.com/JetBrains/JetBrainsRuntime/blob/main/jb/project/docker/Dockerfile.musl_x64 

Not sure if a ticket should be submitted against this issue into JBS because I could not find any info about supporting build platform for at Linux aarch64 musl at https://wiki.openjdk.org/display/Build/Supported+Build+Platforms. Hopefully the list of supported platforms was outdated and aarch64 is still supported...

Thanks
Vitaly

> On 16 Aug 2024, at 10:23, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
> 
> On Thu, 15 Aug 2024 06:12:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
> 
>>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>>> 
>>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>>> 
>>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>>> 
>>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>>> 
>>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>>> 
>>> # Cleanups
>>> 
>>> Cleaned up displaced header usage for:
>>>  * BasicLock
>>>    * Contains some Zero changes
>>>    * Renames one exported JVMCI field
>>>  * ObjectMonitor
>>>    * Updates comments and tests consistencies
>>> 
>>> # Refactoring
>>> 
>>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>>> 
>>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>>> 
>>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>>> 
>>> # LightweightSynchronizer
>>> 
>>> Working on adapting and incorporating the following section as a comment in the source code
>>> 
>>> ## Fast Locking
>>> 
>>>  CAS on locking bits in markWord. 
>>>  0b00 (Fast Locked) <--> 0b01 (Unlocked)
>>> 
>>>  When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>>> 
>>>  If 0b10 (Inflated) is observed or there is to...
>> 
>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Remove newline
> 
> Thanks for all the reviews and contributions.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2292891722

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240820/98a516c5/attachment-0001.htm>