Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added churn testsuite #5101

Merged
merged 17 commits into from
Mar 4, 2024
Merged

Added churn testsuite #5101

Show file tree
Hide file tree
Changes from 11 commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
2833dee
Added churn testsuite
judovana Feb 26, 2024
f6fa4df
instead of pushd, moved to results dir pernamently
judovana Feb 26, 2024
517b988
Added second set of tests - without compressed oops
judovana Feb 26, 2024
e7c6f7c
Moved to system group
judovana Feb 26, 2024
3dc815d
Adjusted description
judovana Feb 26, 2024
4db1633
Removed NOCOMP=-nocoops variant in favour of global setting
judovana Feb 27, 2024
550593a
split churn testsuit to churn_1m_all and churn_5h_all
judovana Feb 27, 2024
655e499
added proper quoting
judovana Feb 27, 2024
1cc8542
Onem ore rename of targets to churn_5h_allGCs and churn_1m_allGCs
judovana Feb 27, 2024
2249bc0
added custom churn testcase
judovana Feb 27, 2024
ec66f1a
Updated README to proeprly describe churn_custom and extend it as needed
judovana Feb 28, 2024
59ebac8
churn_1m_allGCs churn_5h_allGCsare now eclipse and redhat vendor only
judovana Feb 29, 2024
a7457b6
churn_custom is now disabled from automated testing
judovana Feb 29, 2024
b69d963
Adapted readme
judovana Feb 29, 2024
9684763
No longer generate tap files on automated runs
judovana Feb 29, 2024
8826b5d
moved churn to system
judovana Mar 1, 2024
90ec5e7
Limited custom churn to 24h to not overwhel grinder
judovana Mar 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions functional/churn/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# churn
Test targeting garbage collector(s).
The suite is able to operate with all GCs in OpenJDK. If your implementation is missing some, the calls to them will fall. If you have some additional one, an enabling wrapper must be created first.

## Running churn locally
clone https://github.com/rh-openjdk/churn read https://github.com/rh-openjdk/churn/blob/master/README and run run.sh

### Setting up the environment:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Setting up the environment:
### Setting up the environment

Java required. Maven recommended, churn can be compiled via direct javac if needed
Java is used from JAVA_HOME or guessed from PATH.
run.sh can use OTOOL_garbageCollector and OTOOL_JDK_VERSION instead of GC argument. See https://github.com/rh-openjdk/churn/blob/master/README for details.
See https://github.com/rh-openjdk/churn/tree/master/bin for list of supported GCs. The compressed ops in upstream run can be controlled by runner or NOCOMP=-nocoops variable (for run.sh)

## Running via aqavit
judovana marked this conversation as resolved.
Show resolved Hide resolved

The support for compressed ops is handled by aqavit itself. It is currently not sure if churn will be able to honor it. If not, churn will be fixed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The support for compressed ops is handled by aqavit itself. It is currently not sure if churn will be able to honor it. If not, churn will be fixed.
The support for compressed ops is handled by AQAvit itself through the use of the `<variation>` tag in playlist.xml. It is currently not sure if churn will be able to honor it. If not, churn will be fixed.

Similarly the java version and JAVA_HOME are handled by aqavit.
judovana marked this conversation as resolved.
Show resolved Hide resolved

### Executing the testsuite
The `BUILD_LIST of functional/churn` contains three targets:
* _churn_1m_allGCs
* _churn_5h_allGCs
* _churn_custom

There are major differences in them:
* churn_1m_allGCs - is testing ground, which runs each GC only for aprox 10 seconds, to simply see if the setup works
* churn_5h_allGCs - Is running each GC a bit over, which runs each GC for aprox hour and half. A minimum, which can find some real GC issue.
* churn_custom - this one needs you to set and export CHURN_GCS and CHURN_DURATION to select GC(or GCs) and duration. So it allows you to test your custom GC - if churn supports that, despite of anybody else (eg `default` or `ALL` thinks)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* churn_custom - this one needs you to set and export CHURN_GCS and CHURN_DURATION to select GC(or GCs) and duration. So it allows you to test your custom GC - if churn supports that, despite of anybody else (eg `default` or `ALL` thinks)
* churn_custom - this one is to support development, when run on the commandline you need to export CHURN_GCS and CHURN_DURATION to select GC(or GCs) and duration. So it allows you to test your custom GC - if churn supports that, despite what other churn options suggest (eg `default` or `ALL` thinks). When running in a Jenkins Grinder job, can use the APPLICATION_OPTIONS parameter to set CHURN_GCS value and CHURN_DURATION defaults to 5 minutes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had adapt this only partially, as I had not (yet!) followed the APPLICATION_OPTIONS and 5 minutes as you requested (subject of another discussion)


churn_1m_allGCs and churn_5h_allGCs are using pony `ALL` keyword, which is interpreted (based on hardcoded list) as all GC in tested JVM. The set time is divided among them.
Note, that if you use `churn_custom` and enumeration, eg `CHURN_GCS="zgc g1"` then the time will not be divided. The `CHURN_DURATION` is in seconds
The `CHURN_GCS="defaultgc"`will set the tested GC to defautl GC as run.sh think is right. So be aware. Although it is maintained, if your custom JDK have custom GC, it is unlikely to be known
judovana marked this conversation as resolved.
Show resolved Hide resolved

### reading results:
judovana marked this conversation as resolved.
Show resolved Hide resolved
tap file and compressed xmlfile is genrated. Use eg https://github.com/jenkinsci/report-jtreg-plugin or https://plugins.jenkins.io/tap/ to read them.
judovana marked this conversation as resolved.
Show resolved Hide resolved

64 changes: 64 additions & 0 deletions functional/churn/build.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
<?xml version="1.0"?>

<!--
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
-->

<project name="churn" default="build" basedir=".">
<taskdef resource="net/sf/antcontrib/antlib.xml" />
<description>
Test targeting garbage collector(s)
</description>

<!-- set properties for this build -->
<property name="TEST" value="churn" />
<property name="DEST" value="${BUILD_ROOT}/functional/churn" />
<property name="src" location="./churn" />

<target name="THC.check">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opportunity to generalize the name to testcodeDir.check and testCodeDir.exists (which could also be made into an ant macrodef and moved to TKG, but not required for this PR), no need to use same ant target name as the TestHeadlessComponents ant tasks

<condition property="THCdir.exists">
<available file="churn" type="dir"/>
</condition>
</target>

<if>
<contains string="${SPEC}" substring="zos"/>
<then>
<property name="GIT_REPO" value="[email protected]:" />
</then>
<else>
<property name="GIT_REPO" value="https://github.com/" />
</else>
</if>

<target name="getChurn" depends="THC.check" unless="THCdir.exists">
<exec executable="git" failonerror="true">
<arg value="clone" />
<arg value="${GIT_REPO}rh-openjdk/churn.git" />
</exec>
</target>

<target name="init">
<mkdir dir="${DEST}"/>
</target>

<target name="dist" depends="getChurn" description="generate the distribution">
<copy todir="${DEST}">
<fileset dir="${src}" includes="*.xml, *.mk"/>
</copy>
</target>

<target name="build">
<antcall target="dist" inheritall="true" />
</target>
</project>
88 changes: 88 additions & 0 deletions functional/churn/playlist.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
<?xml version='1.0' encoding='UTF-8'?>
<!--
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
-->
<playlist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../TKG/resources/playlist.xsd">
<test>
<testCaseName>churn_1m_allGCs</testCaseName>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

churn_1m_allGCs is for testing only. When the PR is ready for merge can it be disabled by adding tag ?

<command>
export OTOOL_JDK_VERSION="$(JDK_VERSION)" ; \
export JREJDK="jdk" ; \
export OTOOL_garbageCollector="ALL" ; \
export DURATION="60" ; \
export TMPRESULTS="$(Q)$(REPORTDIR)$(D)report$(Q)"; \
cd $TMPRESULTS ; \
bash "$(TEST_ROOT)$(D)functional$(D)churn$(D)churn$(D)run.sh"; \
$(TEST_STATUS)
</command>
<levels>
<level>dev</level>
</levels>
<platformRequirementsList>
<platformRequirements>os.linux</platformRequirements>
<platformRequirements>os.win</platformRequirements>
<platformRequirements>os.osx</platformRequirements>
</platformRequirementsList>
<groups>
<group>system</group>
</groups>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's restrict to particular vendors for now, as I am not sure which vendors include the entire list of GCs that are in 'allGCs' in their distribution (in particular shenandoah) and we do not want to break others.
Add this bit into the <test> block, can be right after the </groups> tag

<vendors>
        <vendor>eclipse</vendor>
        <vendor>redhat</vendor>
</vendors>

</test>
<test>
<testCaseName>churn_5h_allGCs</testCaseName>
<command>
export OTOOL_JDK_VERSION="$(JDK_VERSION)" ; \
export JREJDK="jdk" ; \
export OTOOL_garbageCollector="ALL" ; \
export DURATION="18000" ; \
export TMPRESULTS="$(Q)$(REPORTDIR)$(D)report$(Q)"; \
cd $TMPRESULTS ; \
bash "$(TEST_ROOT)$(D)functional$(D)churn$(D)churn$(D)run.sh"; \
$(TEST_STATUS)
</command>
<levels>
<level>dev</level>
</levels>
<platformRequirementsList>
<platformRequirements>os.linux</platformRequirements>
<platformRequirements>os.win</platformRequirements>
<platformRequirements>os.osx</platformRequirements>
</platformRequirementsList>
<groups>
<group>system</group>
</groups>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

<vendors>
        <vendor>eclipse</vendor>
        <vendor>redhat</vendor>
</vendors>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add this element, But I think the generic openjdk should be for sure here. I now recall, there may be issue with shenandoah on jdk8, but I would rather workaround it in CHURN itself, then exclude generic oepnjdk. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had made the listing of GCs dynamic: rh-openjdk/churn@17f1b83

it is still based on known values, but at least will not enforce not-existing GC. Any advice on enabling more vendors? (compelltyh up to you :) tyvm!!)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can onboard other vendors once we see this running for a few weeks at the project, we are just bringing this in now cautiously, but then can broaden it later (and we will do that by testing it against other vendor distros before enabling them).

</test>
<test>
<testCaseName>churn_custom</testCaseName>
judovana marked this conversation as resolved.
Show resolved Hide resolved
<command>
export OTOOL_JDK_VERSION="$(JDK_VERSION)" ; \
export JREJDK="jdk" ; \
export OTOOL_garbageCollector="${CHURN_GCS}" ; \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export OTOOL_garbageCollector="${CHURN_GCS}" ; \
export OTOOL_garbageCollector="${APPLICATION_OPTIONS}" ; \

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand this requirements:

- export OTOOL_garbageCollector="${CHURN_GCS}" ; \
+export OTOOL_garbageCollector="${APPLICATION_OPTIONS}" ; \
...
- export DURATION="${CHURN_DURATION}" ; \
+ export DURATION="300" ; \

The APPLICATION_OPTIONS is something what is custom in aqavit? Isn't it some more general setup?
The "zgc" or "shenandaoh" can be hardly considered as generic.

To remove custom duration s moreover killing the purpise of the changeset and the suite. If you are developing custom GC or porting JDK to new paltform, you want to run churn on each GC you care about (usually default or the single custom one) for several hours. 300s is useles. Generally any hardcoded value in the "custom" setupo is (IMO) bad.

Can we stay with originals pelase? Or maybe an APPLICATION_OPTIONS contain key=value pairs? (but as GC can be space separated list of GCs, it sounds bad). Or maybe APPLICATION_OPTIONS_GC and APPLICATION_OPTIONS_DURATION ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing your touch to readme - is there eal fear, that some ccrazy eprson will start 20days long churn run? If so, then I would lke to still keep the duration adjsutable, and only eg limit it from top.

if such logic would be desirable, then also the churn_1m_allGCs and churn_5h_allGCs may actually take GC as parameter. And fallback to "ALL" if nothing provided. wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see that I have asked that this churn_custom target is disabled (using the <disables> block I suggested), in that way it does not get run during our automated runs.

Also in our world, no one is allowed to go onto test machines and set CHURN_DURATION and CHURN_GCS environment variables, and we would not want them to do that (for lots of reasons, not the least of which is transparency of machine config).

This leaves me to the point to look at this test target as a useful thing when someone wants to run a Grinder to test a particular GC for a short duration, which is why I suggest leveraging the existing APPLICATION_OPTIONS mechanism for pinpointed testing of a particular GC failure.

All that to be said, feel free to not take those review comments and apply them.

if such logic would be desirable, then also the churn_1m_allGCs and churn_5h_allGCs may actually take GC as parameter. And fallback to "ALL" if nothing provided. wdyt?

Yes, the other option is to remove the churn_custom target altogether from the playlist.xml file in this PR. That would be the expedient way to get this PR through.

Could consider then leveraging APPLICATION_OPTIONS to pass a subset of GCs and if its blank, expect the churn test suite to default to all.

export DURATION="${CHURN_DURATION}" ; \
judovana marked this conversation as resolved.
Show resolved Hide resolved
export TMPRESULTS="$(Q)$(REPORTDIR)$(D)report$(Q)"; \
cd $TMPRESULTS ; \
bash "$(TEST_ROOT)$(D)functional$(D)churn$(D)churn$(D)run.sh"; \
$(TEST_STATUS)
</command>
<levels>
<level>dev</level>
</levels>
<platformRequirementsList>
<platformRequirements>os.linux</platformRequirements>
<platformRequirements>os.win</platformRequirements>
<platformRequirements>os.osx</platformRequirements>
</platformRequirementsList>
<groups>
<group>system</group>
</groups>
</test>
</playlist>
Loading