Clarification regarding the GitHub Actions pre-submit testing
shade at redhat.com
Thu Mar 18 13:18:25 UTC 2021
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.
More information about the jdk-dev