AdoptOpenJDK/TSC

Promote AdoptOpenJDK Version jdk-15.0.1+9

gdams opened this issue · 16 comments

gdams commented

Java Version:

JVM:

  • OpenJ9
  • Hotspot

@AdoptOpenJDK/tsc please can somebody +1 this request?

sxa commented

Have the "missing" test suites on Linux/x64 or Linux-aarch64 (assuming those are the only two) been run? If not I don't think we can ship those.

karianna commented

jdk_foreign_0 => deep history 13/14 passed

This is only on Arm64 and appears to be related to FFI tests in an incubator module. Should these really be in a sanity test suite? CC @smlambert

gdams commented

JDK15 windows (no failures)

TRSS link
Build URL https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk15-pipeline/338/
Started by user George Adams

  • 👍1
smlambert commented

re: #180 (comment)
jdk_foreign is part of the sanity.openjdk set because sanity.openjdk is equivalent to tier1 tests at the OpenJDK project

Looks like that target which contains 19 testcases was passing until now (where now 2/19 testcases fail):
Screen Shot 2020-10-23 at 10 45 32 AM

So that failure requires triage to understand why it now fails (is it an infra/test/product issue?)

From a quick look at 1 of the 2 failing testcases, TestSlices looks like not enough space issue:
Screen Shot 2020-10-23 at 10 52 48 AM

In which case predict that on rerun this testcase would pass and is susceptible to intermittent failures at the mercy of the machine environment, failure is non-blocking. Ideally testcases would check if their requirements can be met before they run, but we see that some openjdk test material is not pro-active/defensive in that way.

andrew-m-leonard commented

openj9:
aarch64XL: Tests all good apart from usual intermittent Jlm failures:

4:23:43  FAILED test targets:
14:23:43  	TestJlmRemoteClassAuth_0
14:23:43  	TestJlmRemoteMemoryAuth_0
14:23:43  	TestJlmRemoteNotifierProxyAuth_0
14:23:43  	TestJlmRemoteThreadAuth_0
14:23:43  	TestIBMJlmRemoteMemoryAuth_0

sanity.openjdk_ppc64le_linux:

pshipton commented

lgtm, no concerns publishing this release.

  • 👍1
smlambert commented

The sanity.openjdk (jdk_lang and jdk_util) failures fail with:
Unable to map CDS archive -- os::vm_allocation_granularity() expected: 4096 actual: 65536

Had not seen that before in openjdk tests, but we have seen before in system test failures on that platform. Not sure if it's correlated to running on certain machines or not.

andrew-m-leonard commented

OpenJ9 jdk15 shipped.

smlambert commented

For hotspot, the MathLoadTest_all issue has been around a while, adoptium/aqa-tests#1893.

There is some recent new info, based on investigation by OpenJ9 team on a different math issue and some digging by @pshipton and @lumpfish ... Hotspot is not as precise in its Math answers as this test material expects or as a StrictMath answer. Java spec does not require an implementation to have Math answer match a StrictMath answer (to same precision).

We will have to decide if we update test material accordingly.

smlambert commented

Rerunning jdk_lang and jdk_util on non-aws aarch64 machines (suspect the failures are machine related).
jdk_lang rerun: https://ci.adoptopenjdk.net/job/Test_openjdk15_hs_sanity.openjdk_aarch64_linux/82
jdk_util rerun: https://ci.adoptopenjdk.net/job/Test_openjdk15_hs_sanity.openjdk_aarch64_linux/84

Since jdk_util rerun saw the original failure pass, but a new failure seen:
java.lang.RuntimeException: FAILED: Pacific/Fiji
at TestZoneInfo310.main(TestZoneInfo310.java:204)

I have kicked off a couple of Grinders (2x4 nodesByIterations): https://ci.adoptopenjdk.net/job/Grinder/4300/
Node1=test-aws-rhel76-armv8-5, jdk_util 4x Grinder
Node2=test-aws-rhel76-armv8-3, jdk_util 4x Grinder

gdams commented

JDK15 hotspot shipped

gdams commented

JDK15 OpenJ9 macOS re-spin:

TRSS link
Build URL https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk15-pipeline/343/
Started by user George Adams

NO TEST FAILURES