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 <abold...@openjdk.org> wrote:
>
> On Thu, 15 Aug 2024 06:12:22 GMT, Axel Boldt-Christmas <abold...@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
