ARM port consolidation

[Bob Vandette]

I agree with David.

I do know that our implementation does run in AArch32 mode and it should be very easy
to add dynamic AArch32 detection in order to make use of the few new AArch32 specific
instructions such as the memory barrier instructions (LDAR/STLR).   Since our current
port already contains ARMv8 instruction pneumonics, we are already 1/2 way there.

Bob.


> On Jun 7, 2018, at 12:56 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Gil,
> 
> On 7/06/2018 2:23 PM, Gil Tene wrote:
>> This makes sense to me on the Aarch64 side.
>> However, on the ARM32 side, I don't think the situation is as straightforward as
>> what is being presented below, and I think more discussion and exploration of
>> alternatives is needed.
>> Much like with AArch64, there is an existing, active, community-developed and
>> community-supported AArch32 port in OpenJDK that predates Oracle's open
>> sourcing of their ARM32 version. That port is being used by multiple downstream
>> builds and, at least for the past year+, it seems to have had more attention and
>> ongoing engineering commitment around it than the Oracle variant.
> 
> To clarify:
> 
> "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1]
> 
> whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports.
> 
> David
> 
> [1] http://openjdk.java.net/projects/aarch32-port/
> 
>> Before making a choice of one AArch32 port vs the other (if such a choice
>> even needs to be made), I would like to hear more about the resources being
>> committed towards maintaining each, keeping each up to date, testing them on
>> various platforms (e.g. including building, testing, and supporting the popular
>> softfloat ABI variants imposed by some OS packages) and working on bug
>> fixes as needs appear.
>> — Gil.
>>> On Jun 4, 2018, at 6:24 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Bob,
>>> 
>>> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev.
>>> 
>>> I think this is a good idea.
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 5/06/2018 6:34 AM, Bob Vandette wrote:
>>>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit
>>>> ARM ports and contributed them to OpenJDK.  These ports have been used for
>>>> years in the embedded and mobile market, making them very stable and
>>>> having the benefit of a single source base which can produce both 32 and
>>>> 64-bit binaries.  The downside of this contribution is that it resulted
>>>> in two 64-bit ARM implementations being available in OpenJDK.
>>>> I'd like to propose that we eliminate one of the 64-bit ARM ports and
>>>> encourage everyone to enhance and support the remaining 32 and 64 bit
>>>> ARM ports. This would avoid the creation of yet another port for these chip
>>>> architectures.  The reduction of competing ports will allow everyone
>>>> to focus their attention on a single 64-bit port rather than diluting
>>>> our efforts.  This will result in a higher quality and a more performant
>>>> implementation.
>>>> The community at large (especially RedHat, BellSoft, Linaro and Cavium)
>>>> have done a great job of enhancing and keeping the AArch64 port up to
>>>> date with current and new Hotspot features.  As a result, I propose that
>>>> we standardize the 64-bit ARM implementation on this port.
>>>> If there are no objections, I will file a JEP to remove the 64-bit ARM
>>>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm
>>>> along with any build logic.  This will leave the Oracle contributed
>>>> 32-bit ARM port and the AArch64 64-bit ARM port.
>>>> Let me know what you all think,
>>>> Bob Vandette