Enable tests builds on azure devops VM agents

[sophia-guo]

Using Azure VM Agents Plugin we can create Jenkins agents in Azure Virtual Machines (via Azure ARM template), which would increase the number of available machines and reduce the jobs' waiting time.

https://ci.adoptopenjdk.net/ has added Azure VM Agents Cloud and configured linux, arrch64, windows Azure VM Agent Template. openjdk-build build jobs has enabled to run the build on those Azure VM agents. https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-x64-hotspot/

We could do something similar.

1. Configure test specific VM Agent with required Label. (After you configured an Azure VM agent template, when you run a new Jenkins job, Jenkins will automatically provision a new Azure VM only if there is no executor available. , looks like this is exactly what we need? if there is agent available then use it. If no, create VM Agent? If that's the case we can use same label as other jenkins agents)
2. Using a Custom VM Image to set tests required environment.(The built-in image only has a clean Windows or Ubuntu OS and some tools like Git and Maven installed, in some cases, you may want to have more customization on the image. ) This could be done by custom image or running Dockerfile.

[aahlenst]

It might make sense to check whether there's enough Azure budget left or can be freed up by removing static machines.

Jenkins will automatically provision a new Azure VM only if there is no executor available.

That is only desirable if the previous job did not alter the machine in any way. The more reliable approach is to always start a new VM (and stop the old one) because all leftovers and stuck processes will be gone. I don't know whether the Jenkins plug-in can do it.

[sophia-guo]

Once Retention Strategy. This retention strategy make sure to use one agent only once.

The plugin has this retention choice. @aahlenst

[smlambert]

This approach can and will be implemented in such a way that ANY cloud provider that has a plugin for spinning up agents can be utilized. We had already trialed this approach with AWS codebuild resources. I could update the title to capture that, but as @sophia-guo suggests, we will first retrial this using the Azure VM agent plugin.

The important part to this is to get the logic correct:

• if test job finds a statically configured agent that is idle, it will use it (this ensures we hit some real hardware if we have it)
• if there are no agents available and idle, it will attempt to spin up a dynamic resource

The test pipeline code will not be aware of which cloud provider would serve up the dynamic resource, it will only know to append an additional label and retry the search for an agent, which will then spin up the dynamic resource.

[sxa]

Three questions:

• Which OSs are in scope for this? Is the only Linux option Ubuntu in the dynamic systems?
• Has this been tested with Windows yet?
• How will they be configured with the test prereqs?

We currently use the dockerBuild label to provision dynamic machines in azure but those are purely set up to run work in docker containers use a pre-configured image pulled form Dockerhub (so we also use the retention value I believe, as the docker containers can get restarted independently of the provisioned VM itself)

[smlambert]

Azure VM agents plugin allows for both xlinux (Ubuntu) and windows agents to be used. (my initial look at the configuration for build tells me we would provision slightly differently for test).

So to answer the questions:

• which OSs are in scope? the ones offered by the plugin (and once this is understood, could revisit AWS codebuild for aarch64 resource, but sounds like economically we have other options/providers)
• has it been tested with Windows yet, answer No. Tested on xlinux yet? No. That is why we raised this issue. This is the placeholder for the work to enable it.
• How will prereqs be configured? Looking now, learning what Azure VM agents plugin offers and what is involved in creating custom VM images, prototype an MVP, see what is possible.

So far, lots of queries and interest on this issue. 👍

Let's not kibosh it before work even begins.

[sxa]

Let's not kibosh it before work even begins.

Haha not my intention at all - just getting an understanding of what's been done already :-) Looking forward to getting it in place and seeing what it can do and how well it works :-)

[sophia-guo]

Thanks @smlambert for enabling linux template to play with. Here are some results ( some code is hard code for testing convenience): using https://github.com/sophia-guo/openjdk-tests/tree/azureVM

if test job finds a statically configured agent that is idle, it will use it (this ensures we hit some real hardware if we have it) https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/229/console

if there are no agents available and idle, it will attempt to spin up a dynamic resource Temporarily hacked by setting a non-existing label: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/225/

How will they be configured with the test prereqs? Currently adoptopenjdk/centos6_build_image works fine. If we do need extra prereqs we can reuse openjdk-tests/buildenv/docker/Dockerfile. Pipeline supports building and running a container from a Dockerfile in the source repository. docker.build("test-image", "./buildenv/docker/")

[sophia-guo]

Running some simple test and got following problems:

1. Only tried with non-parallel ones. With Once Retention Strategy each time it takes 8-10 mins to create a new agent. The data comes from grinders 218-228 https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/ It may be acceptable for non-parallel. For parallel it might be a different story. If more than one jobs are waiting for available agents how should the agent be selected?Should we create dynamic agent immediately ( taking 8 mins) or wait for next available solid agents( there will probably be solid agents available in 8 mins)? And is there a limitation of maximum number of dynamic agent we can create?

2. The different behaviour of jenkins parameters between dynamic agent and solid ones: For solid one, if we leaves parameters as blank they will not be considered as environment variables. However with dynamic ones all parameters will be considered as environment variables, which will make the logic depended on the if environment variable is set wrong.

10:33:21  JDK_BRANCH=
10:33:21  OPENJ9_SYSTEMTEST_REPO=https://github.com/eclipse/openj9-systemtest
10:33:21  OCP_SERVER=
10:33:21  OCP_TOKEN=
10:33:21  RELEASE_TAG=
10:33:21  ARCHIVE_TEST_RESULTS=false
10:33:21  ADOPTOPENJDK_BRANCH=azureVM
10:33:21  UPSTREAM_JOB_NAME=
10:33:21  TEST_IMAGES_REQUIRED=true
10:33:21  JCK_ROOT=
10:33:21  OPENJ9_SHA=
10:33:21  OPENJ9_SYSTEMTEST_BRANCH=master
10:33:21  JVM_VERSION=
10:33:21  DIAGNOSTICLEVEL=noDetails
10:33:21  RUN_ARTIFACTS_DISPLAY_URL=https://ci.adoptopenjdk.net/job/grinder_sandbox/224/display/redirect?page=artifacts
10:33:21  CUSTOM_TARGET=
10:33:21  TEST_FLAG=
10:33:21  PERSONAL_BUILD=true
10:33:21  SPEC=linux_x86-64_cmprssptrs
10:33:21  OPENJDK_SHA=
10:33:21  JDK8_BOOT_DIR=/usr/lib/jvm/java-1.8.0-openjdk.x86_64
10:33:21  ITERATIONS=1
10:33:21  JENKINS_HOME=/home/jenkins/.jenkins
10:33:21  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
10:33:21  KEEP_REPORTDIR=

For example JDK_BRANCH and JDK_REPO is blank. Failed the job https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/224/console

3. The plugin Xvfb doesn't work with dynamic agent?

10:14:31  $ docker exec --env ******** 40c3520c47f909f6dce2d464cd064e6880824cb62acde81a74a79729d0b08eeb Xvfb -displayfd 2 -screen 0 1024x768x24 -fbdir /home/adoptopenjdk/xvfb-223-..fbdir1790491064317157464
10:14:41  Xvfb starting_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
10:14:41  open: No such file or directory
10:14:41  open /home/adoptopenjdk/xvfb-223-..fbdir1790491064317157464/Xvfb_screen0 failed, Invalid argument(EE) 
10:14:41  Fatal server error:
10:14:41  (EE) Couldn't add screen 0(EE) 
10:14:41  unlink: No such file or directory
10:14:41  unlink /home/adoptopenjdk/xvfb-223-..fbdir1790491064317157464/Xvfb_screen0 failed, No such file or directory
10:14:41  ERROR: Xvfb failed to start, consult the lines above for errors

https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/223/console

4. openjdk test failures java/lang/ProcessHandle/OnExitTest.java

12:11:14  ACTION: testng -- Error. Program `/home/adoptopenjdk/workspace/grinder_sandbox/openjdkbinary/j2sdk-image/bin/java' timed out (timeout set to 960000ms, elapsed time including timeout handling was 960442ms).
12:11:14  REASON: User specified action: run testng OnExitTest 
12:11:14  TIME:   960.445 seconds
12:11:14  messages:
12:11:14  command: testng OnExitTest
12:11:14  reason: User specified action: run testng OnExitTest 
12:11:14  Mode: othervm
12:11:14  Additional options from @modules: --add-modules jdk.management
12:11:14  Timeout information:
12:11:14  Running jstack on process 23317

https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/227/console

5. cmdLineTester_callsitedbgddrext_openj9_0_FAILED same as the issue with solid macos, can't find the dump file.

   
   11:52:11  Testing: Run !printallcallsites
   11:52:11  Test start time: 2021/01/21 16:52:11 Coordinated Universal Time
   11:52:11  Running command: /home/adoptopenjdk/workspace/grinder_sandbox/openjdkbinary/j2sdk-image/bin/jdmpview -core j9core.dmp
   11:52:11  Time spent starting: 1 milliseconds
   11:52:12  Time spent executing: 640 milliseconds
   11:52:12  Test result: FAILED
   11:52:12  Output from test:
   11:52:12   [OUT] DTFJView version 4.29.5, using DTFJ version 1.12.29003
   11:52:12   [OUT] Loading image from DTFJ...
   11:52:12   [OUT] 
   11:52:12   [OUT] Could not load dump file and/or could not load XML file: Image file '/home/adoptopenjdk/workspace/grinder_sandbox/openjdk-tests/TKG/test_output_16112479114526/cmdLineTester_callsitedbgddrext_openj9_0/j9core.dmp' not found.
   11:52:12   [OUT] For a list of commands, type "help"; for how to use "help", type "help help"
   11:52:12   [OUT] > DDR is not enabled for this core file, '!' commands are disabled
   11:52:12   [OUT] > 
   11:52:12  >> Success condition was not found: [Output match: jvminit.c]
   11:52:12  >> Failure condition was not found: [Output match: DDRInteractiveCommandException]
   11:52:12  >> Failure condition was not found: [Output match: no shared cache]
   11:52:12  >> Failure condition was not found: [Output match: unable to read]
   11:52:12  >> Failure condition was not found: [Output match: could not read]
   11:52:12  >> Failure condition was not found: [Output match: dump event]
   11:52:12  
   11:52:12  Testing: Run !findallcallsites
   11:52:12  Test start time: 2021/01/21 16:52:11 Coordinated Universal Time
   11:52:12  Running command: /home/adoptopenjdk/workspace/grinder_sandbox/openjdkbinary/j2sdk-image/bin/jdmpview -core j9core.dmp
   11:52:12  Time spent starting: 2 milliseconds
   11:52:12  Time spent executing: 655 milliseconds
   11:52:12  Test result: FAILED
   11:52:12  Output from test:
   11:52:12   [OUT] DTFJView version 4.29.5, using DTFJ version 1.12.29003
   11:52:12   [OUT] Loading image from DTFJ...
   11:52:12   [OUT] 
   11:52:12   [OUT] Could not load dump file and/or could not load XML file: Image file '/home/adoptopenjdk/workspace/grinder_sandbox/openjdk-tests/TKG/test_output_16112479114526/cmdLineTester_callsitedbgddrext_openj9_0/j9core.dmp' not found.
   11:52:12   [OUT] For a list of commands, type "help"; for how to use "help", type "help help"
   11:52:12   [OUT] > DDR is not enabled for this core file, '!' commands are disabled
   11:52:12   [OUT] > 
   11:52:12  >> Success condition was not found: [Output match: jvminit.c]
   11:52:12  >> Failure condition was not found: [Output match: DDRInteractiveCommandException]
   11:52:12  >> Failure condition was not found: [Output match: no shared cache]
   11:52:12  >> Failure condition was not found: [Output match: unable to read]
   11:52:12  >> Failure condition was not found: [Output match: could not read]
   11:52:12  >> Failure condition was not found: [Output match: dump event]
   11:52:12  
   11:52:12  
   11:52:12  ---TEST RESULTS---
   11:52:12  Number of PASSED tests: 3 out of 5
   11:52:12  Number of FAILED tests: 2 out of 5
   11:52:12  

https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/228/console

[sophia-guo]

Note for each run: sanity.openjdk jdk11: one test failure : java/lang/ProcessHandle/OnExitTest.java failed with both hotspot and openj9

12:11:14  ACTION: testng -- Error. Program `/home/adoptopenjdk/workspace/grinder_sandbox/openjdkbinary/j2sdk-image/bin/java' timed out (timeout set to 960000ms, elapsed time including timeout handling was 960442ms).
12:11:14  REASON: User specified action: run testng OnExitTest 
12:11:14  TIME:   960.445 seconds
12:11:14  messages:
12:11:14  command: testng OnExitTest
12:11:14  reason: User specified action: run testng OnExitTest 
12:11:14  Mode: othervm
12:11:14  Additional options from @modules: --add-modules jdk.management
12:11:14  Timeout information:
12:11:14  Running jstack on process 23317

• openj9 with openjdk sanity: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/230/
• hotsopt with openjdk sanity: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/227

sanity.openjdk jdk8: all passed.

• hotsopt : https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/231
• openj9: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/232

[sophia-guo]

sanity.functional

jdk8:

• hotspot : https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/233 : all passed
• openj9 : https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/239 : Failed

jdk11:

• hotspot: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/235: all passed
• openj9 : https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/241: Failed

Both jdk11 and jdk8 failed with same tests. 00:52:50 UnsafeTests_0 00:52:50 UnsafeTests_1 00:52:50 cmdLineTester_SCCommandLineOptionTests_1 00:52:50 cmdLineTester_jvmtitests_debug_3 00:52:50 cmdLineTester_jvmtitests_debug_5 00:52:50 cmdLineTester_jvmtitests_debug_7 00:52:50 cmdLineTester_jvmtitests_debug_8 00:52:50 cmdLineTester_jvmtitests_debug_9 00:52:50 cmdLineTester_jvmtitests_debug_11 00:52:50 cmdLineTester_jvmtitests_debug_openj9_none_SCC_3 00:52:50 cmdLineTester_jvmtitests_debug_openj9_none_SCC_5 00:52:50 cmdLineTester_jvmtitests_debug_openj9_none_SCC_7 00:52:50 cmdLineTester_jvmtitests_debug_openj9_none_SCC_8 00:52:50 cmdLineTester_jvmtitests_debug_openj9_none_SCC_9 00:52:50 cmdLineTester_jvmtitests_debug_openj9_none_SCC_11 00:52:50 cmdLineTester_callsitedbgddrext_openj9_0 00:52:50 cmdLineTester_pltest_0 00:52:50 jit_jar_0

Haven't digged into the reason. Based on same failures may relate with environment.

[smlambert]

You have made fast progress here @sophia-guo ! Great to see!

re: https://github.com/AdoptOpenJDK/openjdk-tests/issues/2181#issuecomment-765468523, I think xvfb is installed on machines from ansible playbooks, so may need it installed as prereq in Dockerfile...

Xvfb is used for a very small subset of test targets jdk_awt, jdk_swing and a few jck targets). Given that so few targets use it, we may consider not setting it up at the start of a test run in Jenkinsfilebase, but call it only at the start of the ~4 test targets that require it, something to think about.

[sophia-guo]

Also tried parallel with retention time setting to 60 mins to avoid recreate the agent and add extra queue time (8 ~ 10 mins) haven't hit the problems.

Scenario : (hack on solid available) step 1: Grinder of grinder (parallel case1 ) to create 4 agent ( 8-10 mins create agents) https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/262/ https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/263/ https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/264/ https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/265/ https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/266/

step 2: Within 60 mins of job finish parallel with NodesByIterations, all available vm agents are reused. https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/267/ generated 5 iteration builds, which use available agents. If no available one then create one.

[sophia-guo]

if test job finds a statically configured agent that is idle, it will use it (this ensures we hit some real hardware if we have it)

Originally I thought that nodesByLabel(LABEL).size() >0 means statically configured agents are available and idle, which is actually wrong. It means the list nodes by Label no matter if the node is idle or not. So we will still need to figure out the case of all available statically agents are busying, i.e. the case of Waiting for next available executor.

[sophia-guo]

Due to the step nodesByLabel(LABEL).size() >0 can't give the information if nodes with specified label are idle or not, updated to use jenkins REST api to get nodes idle information.

Tested using azureVMTest branch ( limit label to be test-ibmcloud-ubuntu1604-x64-1 so it's easy to imitate )

1. No CLOUD_PROVIDER

• job 319: test-ibmcloud-ubuntu1604-x64-1 is not idle, job will wait for next available executor

2. With CLOUD_PROVIDER

• job 320: test-ibmcloud-ubuntu1604-x64-1 is not idle, job will run on vm agent.

It's also tested with parallel:

1. Grinder of grinder : job 330, one job job 333: scheduled to test-ibmcloud-ubuntu1604-x64-1 and all others job 331, 332, 334 :scheduled to vmagent
2. Parallel by NodesByIterations job 336 within 60 mins of vmagent retention, job will be scheduled to test-ibmcloud-ubuntu1604-x64-1 job iterate 0 or available vmagent or create a new one is there is no existing one available job iterate 1,2,3

[sophia-guo]

Currently using image adoptopenjdk/centos6_build_image. Next step would be if there are other platform agent available or the image adoptopenjdk/centos6_build_image doesn't work for our situation we can also use customized imagehttps://github.com/AdoptOpenJDK/openjdk-tests/issues/2181#issuecomment-765440300.

It could happen that node status changes to idle right after we check it though chances is not big as nightly | release test jobs normally takes time.

We have no idea about the limitation of vm agent ( hours, numbers, etc) so the situation of no vm agents could be created hasn't been taken consideration yet.

[llxia]

It may be worth looking into this Jenkins API to check if a machine is idle: https://stackoverflow.com/questions/37227562/how-to-know-whether-the-jenkins-build-executors-are-idle-or-not-in-jenkins-using

[sophia-guo]

Latest run in AdoptOpenJDK with azure vm agent sanity:

openjdk test:

sanity, 8, hotspot/openj9 : passed

sanity, 11, hotspot/openj9: one test failure : java/lang/ProcessHandle/OnExitTest.java https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/16/testReport/java_lang_ProcessHandle_OnExitTest/java/OnExitTest/ https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/17/

Functional:

sanity, 8/11, hotspot: passed

sanity, 8, openj9: failed tests: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/20/console

10:33:50  FAILED test targets:
10:33:50    cmdLineTester_callsitedbgddrext_openj9_0
10:33:50    cmdLineTester_pltest_0
10:33:50    cmdLineTester_GCCheck_0
10:33:50    cmdLineTester_GCCheck_1
10:33:50    cmdLineTester_GCCheck_2
10:33:50    cmdLineTester_GCCheck_3
10:33:50    cmdLineTester_GCCheck_4
10:33:50    cmdLineTester_SCCommandLineOptionTests_0
10:33:50    cmdLineTester_SCCommandLineOptionTests_1
10:33:50    cmdLineTester_jvmtitests_debug_0
10:33:50    cmdLineTester_jvmtitests_debug_1
10:33:50    cmdLineTester_jvmtitests_debug_2
10:33:50    cmdLineTester_jvmtitests_debug_3
10:33:50    cmdLineTester_jvmtitests_debug_4
10:33:50    cmdLineTester_jvmtitests_debug_5
10:33:50    cmdLineTester_jvmtitests_debug_6
10:33:50    cmdLineTester_jvmtitests_debug_7
10:33:50    cmdLineTester_jvmtitests_debug_8
10:33:50    cmdLineTester_jvmtitests_debug_9
10:33:50    cmdLineTester_jvmtitests_debug_10
10:33:50    cmdLineTester_jvmtitests_debug_11
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_0
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_1
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_2
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_3
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_4
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_5
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_6
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_7
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_8
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_9
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_10
10:33:50    cmdLineTester_jvmtitests_debug_openj9_none_SCC_11
10:33:50    UnsafeTests_SE80_0
10:33:50    UnsafeTests_SE80_1
10:33:50    jit_jar_0
10:33:50    TestRefreshGCSpecialClassesCache_BCI_EXTENDED_HCR_SE80_0

sanity, 11, openj9: failed tests: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/22/console

11:01:38  FAILED test targets:
11:01:38    cmdLineTester_callsitedbgddrext_openj9_0
11:01:38    cmdLineTester_pltest_0
11:01:38    cmdLineTester_GCCheck_0
11:01:38    cmdLineTester_GCCheck_1
11:01:38    cmdLineTester_GCCheck_2
11:01:38    cmdLineTester_GCCheck_3
11:01:38    cmdLineTester_GCCheck_4
11:01:38    cmdLineTester_SCCommandLineOptionTests_0
11:01:38    cmdLineTester_SCCommandLineOptionTests_1
11:01:38    cmdLineTester_jvmtitests_debug_0
11:01:38    cmdLineTester_jvmtitests_debug_1
11:01:38    cmdLineTester_jvmtitests_debug_2
11:01:38    cmdLineTester_jvmtitests_debug_3
11:01:38    cmdLineTester_jvmtitests_debug_4
11:01:38    cmdLineTester_jvmtitests_debug_5
11:01:38    cmdLineTester_jvmtitests_debug_6
11:01:38    cmdLineTester_jvmtitests_debug_7
11:01:38    cmdLineTester_jvmtitests_debug_8
11:01:38    cmdLineTester_jvmtitests_debug_9
11:01:38    cmdLineTester_jvmtitests_debug_10
11:01:38    cmdLineTester_jvmtitests_debug_11
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_0
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_1
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_2
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_3
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_4
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_5
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_6
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_7
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_8
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_9
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_10
11:01:38    cmdLineTester_jvmtitests_debug_openj9_none_SCC_11
11:01:38    UnsafeTests_0
11:01:38    UnsafeTests_1
11:01:38    jit_jar_0

[sophia-guo]

Latest run in AdoptOpenJDK with azure vm agent

Target extended Category openjdk

8, openj9: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/37/console

11:48:58  FAILED test targets:
11:48:58    jdk_imageio_0
11:48:58    jdk_imageio_1

8, hotspot: https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/36/console

12:09:31  FAILED test targets:
12:09:31    hotspot_jre_1
12:09:31    jdk_tools_1
12:09:31    jdk_jfr_1
12:09:31    jdk_imageio_1

11, openj9 https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/39/console

13:09:42  FAILED test targets:
13:09:42    jdk_imageio_0
13:09:42    jdk_imageio_1

11, hotspot https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/38/console

13:25:16  FAILED test targets:
13:25:16    jdk_beans_1
13:25:16    jdk_tools_1
13:25:16    jdk_imageio_1

functional:

8|11, hotspot: passed https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/41/

8, openj9: failed https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/42

13:34:35  FAILED test targets:
13:34:35    testDDRExt_General_0
13:34:35    testDDRExt_Class_0
13:34:35    testDDRExt_Callsites_0
13:34:35    testDDRExt_JITExt_0
13:34:35    testDDRExt_SharedClasses_0
13:34:35    testDDRExtJunit_CollisionResilientHashtable_0
13:34:35    testDDRExtJunit_StackMap_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock1_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock1_1
13:34:35    testDDRExtJunit_MonitorsAndDeadlock2_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock2_1
13:34:35    testDDRExtJunit_MonitorsAndDeadlock3_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock3_1
13:34:35    testDDRExtJunit_MonitorsAndDeadlock4_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock4_1
13:34:35    testDDRExtJunit_MonitorsAndDeadlock5_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock5_1
13:34:35    testDDRExtJunit_MonitorsAndDeadlock6_0
13:34:35    testDDRExtJunit_MonitorsAndDeadlock6_1
13:34:35    testDDRExtJunit_FindExtThread_0
13:34:35    SyntheticGCWorkload_concurrentSlackAuto_10M_J9_0
13:34:35    cmdLineTester_classesdbgddrext_0
13:34:35    cmdLineTester_classesdbgddrext_1
13:34:35    cmdLineTester_pltest_j9sig_ext_0
13:34:35    testSCCMLTests2_0
13:34:35    testSCCMLTests2_1
13:34:35    testSCCMLTests4_0
13:34:35    testSCCMLTests4_1
13:34:35    cmdLineTester_shrcdbgddrext_0
13:34:35    cmdLineTester_shrcdbgddrext_1
13:34:35    cmdLineTester_dumpromclasstests_0
13:34:35    TestJcmd_0
13:34:35    gcPolicyNogcTest_0
13:34:35    gcPolicyNogcTest_1
13:34:35    gcPolicyNogcOOMTest_0
13:34:35    gcPolicyNogcOOMTest_1
13:34:35    testJCMMXBeanLocal_SE80_0
13:34:35    testOpenJ9DiagnosticsMXBean_0
13:34:35    testRASAPI_0
13:34:35    TestRefreshGCSpecialClassesCache_BCI_EXTENDED_HCR_JIT_ON_SE80_0
13:34:35    TestGCClassWithStaticRetransformInGencon_SE80_0
13:34:35    TestGCClassWithStaticRetransformInBalanced_SE80_0

11, openj9: failed https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox_new/44/console

13:36:09  FAILED test targets:
13:36:09    testDDRExt_General_0
13:36:09    testDDRExt_Class_0
13:36:09    testDDRExt_Callsites_0
13:36:09    testDDRExt_JITExt_0
13:36:09    testDDRExt_SharedClasses_0
13:36:09    testDDRExtJunit_CollisionResilientHashtable_0
13:36:09    testDDRExtJunit_StackMap_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock1_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock1_1
13:36:09    testDDRExtJunit_MonitorsAndDeadlock2_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock2_1
13:36:09    testDDRExtJunit_MonitorsAndDeadlock3_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock3_1
13:36:09    testDDRExtJunit_MonitorsAndDeadlock4_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock4_1
13:36:09    testDDRExtJunit_MonitorsAndDeadlock5_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock5_1
13:36:09    testDDRExtJunit_MonitorsAndDeadlock6_0
13:36:09    testDDRExtJunit_MonitorsAndDeadlock6_1
13:36:09    testDDRExtJunit_FindExtThread_0
13:36:09    SyntheticGCWorkload_concurrentSlackAuto_100k_J9_0
13:36:09    SyntheticGCWorkload_concurrentSlackAuto_10M_J9_0
13:36:09    cmdLineTester_classesdbgddrext_0
13:36:09    cmdLineTester_classesdbgddrext_1
13:36:09    cmdLineTester_pltest_j9sig_ext_0
13:36:09    cmdLineTester_modularityddrtests_0
13:36:09    cmdLineTester_modularityddrtests_1
13:36:09    testSCCMLTests2_0
13:36:09    testSCCMLTests2_1
13:36:09    testSCCMLTests4_0
13:36:09    testSCCMLTests4_1
13:36:09    cmdLineTester_shrcdbgddrext_0
13:36:09    cmdLineTester_shrcdbgddrext_1
13:36:09    cmdLineTester_dumpromclasstests_0
13:36:09    TestJcmd_0
13:36:09    gcPolicyNogcTest_0
13:36:09    gcPolicyNogcTest_1
13:36:09    gcPolicyNogcOOMTest_0
13:36:09    gcPolicyNogcOOMTest_1
13:36:09    testOpenJ9DiagnosticsMXBean_0
13:36:09    testRASAPI_0
13:36:09    TestRefreshGCSpecialClassesCache_BCI_EXTENDED_HCR_0
13:36:09    TestRefreshGCSpecialClassesCache_BCI_EXTENDED_HCR_1
13:36:09    TestGCClassWithStaticRetransformInGencon_0
13:36:09    TestGCClassWithStaticRetransformInBalanced_0