RFR: 8282392: [zero] Build broken on AArch64 [v2]

[Magnus Ihse Bursie]

On Tue, 1 Mar 2022 09:42:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> That's what we looked at and it was more of a mess, IMO. In the end it's a judgment call which to have, and I've seen this kind of mistake, where a particular port is confused with a particular CPU, enough times that I think this is OK; YMMV.
>> 
>> From the perspective of Zero maintenance, having the Zero-specific workarounds explicitly doing `!ZERO` is cleaner. This mess is mostly Zero-s problem with idenitifying itself as CPU. So, in my mind, there is little reason to accommodate that problem with "port" defines.
>
>> Sorry I missed this but this is stylistically awful IMHO. What is AARCH64_PORT_ONLY supposed to mean? IIUC it really means AARCH64_NATIVE_PORT_ONLY or AARCH64_NOT_ZERO_ONLY. I would much rather have seen @shipilev request to use a combination of CPU and ZERO to get this right - as used everywhere else when dealing with ZERO. And we don't use TARGET_ARCH_x anywhere else in the code other than to define the macros.
> 
> I've seen this problem repeating over the years, caused by a failure to distinguish between an ifdef for the properties of a particular CPU and one for the implementation of a particular port. Courtesy of Zero, there is not a 1:1 mapping between these, and (judging by the problems we've seen) it is a frequent cause of confusion. Usually we catch the bugs before push, but not always.
> 
> In my opinion that this is not merely a matter of people making mistakes, but of a style that is confusing, and will continue to be.

@theRealAph Hear, hear!

Zero is causing a conceptual mess the way it is currently "injected" into hotspot. This mess also spills over into the build system.

The core problem is that Zero claims to be a "CPU", which it clearly is not. And then a lot of workarounds needs to be installed everywhere to compensate for this confusion. A better solution would be to go back to CPU meaning just CPU, and introduce a second dimension along which to determine zero/non-zero. We might have to bikeshed for a while to find a good name for this second dimension (I can't come up with any ideal names straight away, anyway. INTERPRETED_ONLY vs COMPILED? ZERO vs NON_ZERO? Or ZERO vs ONE? :-))

Doing this would simplify the concepts and logic behind both the Hotspot code and the build system, and eliminate a class of errors that keep popping up all the time, due to this confusing design decision.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7633