StubRoutines::load_long_atomic causes SIGBUS on aarch32

[Sergei Ustimenko]

HI Boris,

I have following configuration:

```
Configuration summary:
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds cmsgc compiler1 compiler2 epsilongc g1gc jfr
jni-check jvmti management nmt parallelgc serialgc services vm-structs'
* OpenJDK target: OS: linux, CPU architecture: arm, address length: 32
* Version string: 13-internal+0-adhoc.pi.sandbox (13-internal)

Tools summary:
* Boot JDK:       openjdk version "11.0.1-ojdkbuild" 2018-10-16 OpenJDK
Runtime Environment (build 11.0.1-ojdkbuild+13) OpenJDK Server VM (build
11.0.1-ojdkbuild+13, mixed mode)  (at /home/pi/soft/jdk-11.0.1)
* Toolchain:      gcc (GNU Compiler Collection)
* C Compiler:     Version 6.3.0 (at /usr/bin/gcc)
* C++ Compiler:   Version 6.3.0 (at /usr/bin/g++)

Build performance summary:
* Cores to use:   1
* Memory limit:   927 MB
```

When debugging, I see uint64_t aligned at the 4 bytes boundary.
I guess I need to try it out with ARM ABI. Thanks for the reference!

Regards,
Sergei

On Wed, 9 Jan 2019 at 12:56, Boris Ulasevich <boris.ulasevich at bell-sw.com>
wrote:

> Hi Sergei,
>
> On 31.12.2018 2:06, Sergei Ustimenko wrote:
> > Hi Andrey,
> >
> > Sorry for keep you waiting. I've checked with the latest
> > jdk12 and it yields the same result.
> >
> > I got to make myself clear on how I'm actually getting the
> > java binaries in the first place. So I'm  building and running
> > the test using the very same machine (armv7-a). Hotspot
> > compilation is done using GCC. In my case
> >
> > uint64_t volatile InstanceKlass::_dep_context_last_cleared
> >
> > has word alignment and later in the
>
> What toolchain do you use to build jdk? ARM ABI states that 64-bit data
> is 8-byte aligned.
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0042f/index.html
>
> > DependencyContext::claim_cleanup
> >
> > causes the problem.
> > So I've checked against jdk12 tip - same results,
> > I wanted to check against jdk11 - and I have some problems of
> > other sort. Though the cross-compiled jdk11 seems to work fine.
> > I'm not entirely sure on that so I'll check.
> >
> > I just wonder if in the worst case the alignment would need to be
> > changed, what would be the best option.
> >
> > Anyway, thanks for your time and advice.
> >
> > Cheers,
> > Sergei
> >
> >
> > On Sun, 30 Dec 2018 at 00:58, Andrey Petushkov <
> andrey.petushkov at gmail.com>
> > wrote:
> >
> >> hi Sergei,
> >>
> >> yes, this looks like it. and the reason I think it's that you are using
> >> Java 13 code base, which is quite far from release state. at the same
> time
> >> support for 32 bit platforms declines apparently, hence such kind of
> bugs
> >> are imminent. may I suggest you to try version 11 or at least 12 and
> check
> >> whether the problem goes away?
> >>
> >> regards,
> >> Andrey
> >>
> >> сб, 29 Дек 2018 г., 19:28 Sergei Ustimenko <merkel05 at gmail.com>:
> >>
> >>> Hi again,
> >>>
> >>> I had to mention that I've checked the reference manual on armv7-a
> >>> and it says that address in the base register have to be doubleword
> >>> aligned. Most likely that causes SIGBUS. Though I just wanted to know
> >>> if anyone faced that before and may provide some quick tips.
> >>>
> >>> Thanks,
> >>> Sergei
> >>>
> >>> On Sat, 29 Dec 2018 at 17:01, Sergei Ustimenko <merkel05 at gmail.com>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Recently I've stumbled upon quite curious situation in the aarch32
> port.
> >>>> I have latest raspberry pi 3b+ which has an armv8-a CPU, that works
> >>>> in the compatibility mode. Raspbian in that case shows me that CPU
> >>>> is in the 32 bits mode and uses armv7-a instructions set.
> >>>>
> >>>> When I was building and testing the sandbox flavor of openjdk, amongst
> >>>> some tests that failed I've noticed an unusual one:
> >>>>
> >>>> TestAnonymousClassUnloading.java fails with:
> >>>>
> >>>> #  SIGBUS (0x7) at pc=0x73db4884, pid=5430, tid=5435
> >>>> #
> >>>> # JRE version: OpenJDK Runtime Environment (13.0) (build
> >>>> 13-internal+0-adhoc.pi.sandbox)
> >>>> # Java VM: OpenJDK Server VM (13-internal+0-adhoc.pi.sandbox, mixed
> >>> mode,
> >>>> sharing, serial gc, linux-arm)
> >>>> # Problematic frame:
> >>>> # v  ~StubRoutines::atomic_load_long
> >>>>
> >>>> r0  = 0x5bde8e94
> >>>> 0x5bde8e94 is pointing into metadata
> >>>>
> >>>> pc  = 0x73db4884
> >>>> 0x73db4884 is at begin+4 in a stub
> >>>> StubRoutines::atomic_load_long [0x73db4880, 0x73db488c[ (12 bytes)
> >>>>
> >>>> StubRoutines::atomic_load_long [0x73db4880, 0x73db488c[ (12
> >>>> bytes)[Disassembling for mach='arm']
> >>>>    0x73db4880: ldrexd    r0, [r0]
> >>>>    0x73db4884: clrex
> >>>>    0x73db4888: bx        lr
> >>>> VM_Operation (0x643fe5f8): GenCollectFull, mode: safepoint, requested
> by
> >>>> thread 0x7609fc00
> >>>>
> >>>> Does anybody have any suggestion where I could read on why the `clrex`
> >>>> caused SIGBUS?
> >>>>
> >>>> Regards,
> >>>> Sergei
> >>>>
> >>>
> >>
>