Bisection shows it started to happen after JDK-8253660. I believe `toString()` there is not very resilient in the face of `null` causes. I suspect that is what causes Windows x86_64 tier1/compiler failures in GitHub workflows too.

Example output:

$ make run-test TEST=compiler/aot

STDERR:
java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.getCause()" because "<local1>" is null
at jdk.test.lib.artifacts.ArtifactResolverException.getRootCause(ArtifactResolverException.java:22)
at jdk.test.lib.artifacts.ArtifactResolverException.toString(ArtifactResolverException.java:17)
at java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453)
at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:408)
at compiler.aot.AotCompiler.resolveLinker(AotCompiler.java:270)
at compiler.aot.AotCompiler.launchCompiler(AotCompiler.java:112)
at compiler.aot.AotCompiler.main(AotCompiler.java:78)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
at java.base/java.lang.Thread.run(Thread.java:832)