Clarification regarding the GitHub Actions pre-submit testing

[Aleksey Shipilev]

Hi,

On 3/18/21 1:22 AM, mark.reinhold at oracle.com wrote:
> As Alan’s summary suggests, in practice we already have two categories
> of ports -- we just don’t have names for them.
> 
>    - _Primary ports_ (for lack of a better term) are the most broadly
>      used.  They can be built and tested on hardware and software
>      platforms that are commonly available.
> 
>      Examples of primary ports: linux-{x64,aarch64}, windows-x64, macosx-x64
> 
>      If the build or testing of a primary port breaks in the main line
>      then those responsible for the change generally scramble to fix it.
>      A change that requires porting work cannot be integrated into the
>      main line until it supports all of the primary ports.

FWIW, it is odd to see linux-aarch64 in this list. For all the progress aarch64 made in these years, 
linux-aarch64 is still not as commonly available as one might hope. GHA also has no linux-aarch64 
hosts to run any tests on, AFAIU. If we are drawing the line in the sand based on what the regular 
developer has, it leaves only x86_64.


>    - _Secondary ports_ (again, for lack of a better term) are less
>      broadly used, though they are important to some developers and
>      companies.  Building them often requires hardware and software
>      platforms that are not commonly available.
> 
>      Examples of secondary ports: linux-{arm,ppc64,s390}, aix-ppc64
> 
>      If the build or testing of a secondary port breaks in the main line
>      then those who maintain that port generally fix it.  A change that
>      requires porting work can be integrated into the main line without
>      supporting the secondary ports, but contributors of such changes are
>      encouraged to assist the maintainers of the secondary ports in doing
>      the necessary porting work.

Yes.

There is a major minor thing to mention here. The overwhelming majority of the issues are simple 
omissions that break builds/tests in a painfully obvious way. The contributors I worked with are 
usually saying something like "I would have fixed this trivial issue if I knew it was broken!". The 
breakages are very seldom intentional, they mostly come from the absence of mechanical checks that 
would warn a contributor. GHA gives the warning that something is broken, providing the contributor 
to push the day-1 high-grade patch.

Our only GHA workflow, as it stands right now, builds:
   windows-x86_64
   macos-x86_64
   linux-x86_64
   linux-x86_32
   windows-aarch64 (only hotspot)
   linux-x86_64-fastdebug (only hotspot)
   linux-x86_64-optimized (only hotspot)
   linux-x86_64-minimal (only hotspot)
   linux-x86_64-zero (only hotspot)
   linux-ppc64le (only hotspot)
   linux-s390x (only hotspot)
   linux-arm (only hotspot)
   linux-arch64 (only hotspot)

...and runs tier1 on:
   windows-x86_64
   macos-x86_64
   linux-x86_64
   linux-x86_32

So for "secondary ports", GHA overwhelmingly verifies buildability.

Which is good for a litmus test: it verifies that JDK is not significantly broken to block the 
arch-specific testing in the vendor-specific testing systems. True, the contributors are not 
expected to fix the arch-specific test issues for the platforms they do not maintain. But that is 
not what current GHA workflow effectively asks. It asks to pass a low bar of keeping the master 
buildable on those port arches, so porter's CIs can still run tests. I say "low bar" from experience 
of fixing arch-specific build failures over the years. Most of the time those are trivial few-liners.

In fact, the amount of follow-up "build is broken" fixes I submitted after GHA workflows covered 
most of the bases had dwindled to nearly zero. I don't see Linaro's or others CIs complain about 
broken builds as often now. Which in my mind makes the global GHA workflow a resounding success in 
simplifying the OpenJDK development.

> Assuming that we agree on this story so far, where does that leave the
> 32-bit ports presently tested in GitHub actions?  Primary, or secondary?

I believe buildability on x86_32 is as important to enforce as buildability on foreign arches like 
aarch64, arm, ppc64, s390x. The 32/64 bit cleanliness issues in a languages like C/C++ are 
unfortunately only exposed by an attempt to build. x86_32 is special in this regard, because you can 
easily do the reduced build on x86_64.

I agree that running tier1 on x86_32 might not be necessary. Most of the time, x86_32 tests catch 
the test configuration problems that would manifest uniformly across x86_32, ARM32, MIPS, etc. -- 
with the benefit of being able to reproduce x86_32 locally on x86_64 host.

So I am kind of on the fence. x86_32 is at least "secondary".

> Where does that leave windows-aarch64, and the forthcoming macos-aarch64?

Windows-aarch64 is built like a foreign arch in current GHA, and I believe it should continue to 
build. I hope when/if GH adds macos-aarch64, we would build it as foreign arch on GHA as well. Both 
seem "secondary".

> Must Valhalla’s JEP 401 (Primitive Objects) support windows-aarch64,
> macos-aarch64, linux-{arm,ppc64,s390}, and aix-ppc64 before it’s
> integrated?

Based on what I said above:

Support, as in fully passing at least tier1 tests on a secondary platform, while nice to have, is 
not necessary. Being buildable and hopefully failing (more or less) gracefully/consistently at 
runtime -- should be strongly considered, unless there are good reasons why would e.g. stubbing out 
the other arches implementations would not work to regain the buildability.

It is fine to have some platforms build-broken when projects are developed outside the mainline. But 
when the contribution to the mainline happens, I think it is fair to ask to meet this -- quite low! 
-- standard of being buildable everywhere. Unless, of course, there is a sound reason why it is 
complicated to do. In that case, I would hope that porters get notified about these issues before 
the integration happens, so they can implement missing parts sooner.

-- 
Thanks,
-Aleksey