Clarification regarding the GitHub Actions pre-submit testing

[Aleksey Shipilev]

On 3/18/21 12:32 PM, Alan Bateman wrote:
> On 18/03/2021 08:29, Aleksey Shipilev wrote:
>> 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
> "build everywhere" is a high bar in the context of JEPs from big
> projects such as Project Valhalla or Loom that may have a lot of
> architecture specific code. 

I agree that you cannot force Valhalla/Loom/etc developers to _implement_ the architecture-specific 
code for secondary ports.

What I am talking about is much weaker: buildability. I believe it is fair to ask that when the 
mainline integration PR is done, the arch-specific code is clearly isolated, new declarations in 
arch-specific headers are done, their implementations are stubbed out with NotImplemented(), etc.

So that VM builds, and then hopefully passes old tests as much as possible, and fails on new tests 
at sensible points where the implementation is expected to be. I am saying this with the experience 
of doing so multiple times across many JDK releases: that is a low bar to pass. It becomes painful 
when code does not fit the Hotspot's established ways to isolate the arch-specific code. In other 
words, that pain is instructional.

Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from 
the shared code. As I said before, it is a fair game for non-mainline development to hack the 
prototypes any way they want, including focusing only on one platform at a time. But if we decide to 
integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable, 
and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That 
is, GHA would be a very basic quality gate working as intended.

I hope this clarifies that I am not suggesting something drastic here. I am only talking about the 
basic quality gate check: buildability on primary/secondary ports; tier1 on primary ports.

-- 
Thanks,
-Aleksey