arm32 status

[Doerr, Martin]

Hi,

note that Shenandoah has similar prerequisites as zGC with JDK17 which include at least:

Load barriers in interpreter:
OopHandle should use Access API:
https://bugs.openjdk.java.net/browse/JDK-8260369

Concurrent Class Unloading:
nmethod entry barriers:
https://bugs.openjdk.java.net/browse/JDK-8260372

And very recently: Concurrent Thread-Stack Processing
ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing:
https://bugs.openjdk.java.net/browse/JDK-8253180

These ones are currently missing on PPC64, too.

Best regards,
Martin


> -----Original Message-----
> From: shenandoah-dev <shenandoah-dev-retn at openjdk.java.net> On
> Behalf Of Peter Johnson
> Sent: Dienstag, 2. Februar 2021 20:16
> To: Aleksey Shipilev <shade at redhat.com>
> Cc: shenandoah-dev at openjdk.java.net
> Subject: Re: arm32 status
> 
> On Tue, Feb 2, 2021 at 8:04 AM Aleksey Shipilev <shade at redhat.com>
> wrote:
> > On 2/2/21 4:53 PM, Peter Johnson wrote:
> > > Is anyone actively working on arm32 support?  The wiki says "in
> > > development, help wanted" and Aleksey’s Sept 2019 presentation says
> > > "prototyping," but it doesn’t appear like there’s anything committed in
> > > hotspot/cpu/arm/gc. Does anyone have a work in progress on a personal
> fork?
> >
> > I had started it at pre-COVID times, but then we had to stabilize ARM32
> itself. Once we reached some
> > level of ARM32 stability, other things preempted further ARM32 work. I
> have restarted the ARM32 port
> > work yesterday, but -- kid you not -- I have to stabilize ARM32 itself before
> continuing! Such is life.
> >
> > So the bird-eye-view status is: the port is not even in alpha stage.
> >
> > What is your interest? Are you willing to contribute the port? :)
> 
> I'm willing to help, but I'm worried that taking on the full
> implementation is a bit too much of a hill for me to climb in a
> reasonable timeframe (particularly if ARM32 itself is unstable!).
> I've worked before at this level in x86 assembly, but not in ARM, and
> I've not worked on the JDK codebase before.  In reviewing the aarch64
> implementation, it looks like the barrierSetAssembler is the critical
> component?  In comparing other barrierSetAssembler implementations
> between aarch64 and arm, there is significant similarity but also
> non-obvious (to me) differences, so I'd be worried about missing
> something fundamental when porting Shenandoah.
> 
> --
> Thanks,
> -Peter