Is jdk-submit no longer available for committers?

[Aleksey Shipilev]

On 11/24/21 10:12 AM, Jaikiran Pai wrote:
> I'm not sure. I myself hadn't used it previously. The introduction
> mail[1] hadn't mentioned any specific tiers/tests so I always assumed
> that it would run all tests against all the tested platforms.

Running all tests would be prohibitively expensive. On my TR 3970X tier{1,2,3,4} together complete 
in about 10 hours, and that is _one_ configuration. Pull in different GCs, different JIT compilers, 
some verification options, and the whole pipeline starts to be over 100 hours on a very large machine.

> You are right indeed. Before sending this mail, I had triggered a
> (subset) of tier2 (specifically jdk:tier2) on my local setup and that
> just completed a while back. So that indeed is good news for me for any
> future testing. My previous attempt at running tier2 around a year back
> wasn't so successful and I had to kill it after multiple hours of it
> continuing to run.

Over the years, we did a lot of work to make tiered testing viable. Lower tiers should complete 
faster and more reliably than higher tiers, so you are advised to run as many tiers as your 
environment allows.

You might want to read the updated docs here:
   https://github.com/openjdk/jdk/blob/master/doc/testing.md#common-test-groups

> For tier1 testing GitHub Actions has indeed been very helpful,
> especially the ability to trigger manual builds of specific branches
> against specific platforms of choice. I wonder if I can come up with a
> new GitHub workflow to trigger tier2 tests for all platforms against it
> - perhaps not for each PR but for manual/on-demand runs. I'll experiment
> a bit some time soon.

Yes, having the GitHub workflow definitions for tier{2,3,4} *might* be nice, as long as they do not 
trigger automatically. This always runs into the question who actually pays for the GH infra running 
tests and what are the practical usage limits there. Running tier1 on PRs is already quite expensive 
CPU-time wise.

So, for practical reasons, I would advise to invest in local development machine that could run 
higher tiers without bothering the shared infrastructure :) Developing non-trivial OpenJDK 
improvements without substantial CPU resources would always be an exercise in patience otherwise.

-- 
Thanks,
-Aleksey