Added churn testsuite #5101

judovana · 2024-02-26T18:03:01Z

churn testsuite is powerful suite to test individual GCs in OpenJDK

As it is added heere, it tests all GCs in given version of jdk.
Initial pass is https://ci.adoptium.net/view/Test_grinder/job/Grinder/8946/
As it is now - for review process, it runs for some 20 seconds - that means aprox 4 seconds per GC, which i moreover useless. In GH actions (https://github.com/rh-openjdk/churn/actions) I run it on all platforms for aprox 3 minutes per GC, whcih is still moreover useless.
Exept running as it is, it can also run in disabled compressed oops mode. Not sure if it is required here. To run both, should be easy. To make it configurable.. not sure...

Few questions:

the site generates archive full of logs, which are sueprusefull in case of failure. How to propagate them? Or maybe it is done correctly? If so how to see them in grinder?-)
what is acceptable time for you to run churn? I left in comment suggesting 5hours for all GCS (so aprox 1hour per gc - close to be usefull)
there is archive with results for jtreg plugin. It contains single juni xml file. Can it be somehow publised?
Are you ok with running all gcs in one task?
- the individual GCs are reported separately in both logs archive and in junit xml file
- it woudl be nice to have them reported as individual taps or at least individual targets or somethng liek that.. but It is not strightforward to select correct set of GCs per JDK, so I would rather remain in current ALL
- Despite I would liek to see above, I'm not sure it is possible. The logs from several hours long run are huge

judovana · 2024-02-26T18:10:10Z

Grinder with disabled compressed oops https://ci.adoptium.net/view/Test_grinder/job/Grinder/8948/

smlambert

Going to put a request changes on this PR, so it doesn't get merged before all your questions get answered. I have added some review comments in-line, and will answer some other questions shortly.

My immediate question is what happens when this testcase is run against distributions that do not ship with certain GCs. This likely also relates to your question about running each GC as a separate testcase.

functional/churn/build.xml

smlambert · 2024-02-26T18:13:44Z

functional/churn/build.xml

+	<property name="DEST" value="${BUILD_ROOT}/functional/churn" />
+	<property name="src" location="./churn" />
+
+	<target name="THC.check">


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

smlambert · 2024-02-26T18:18:17Z

functional/churn/playlist.xml

+-->
+<playlist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../TKG/resources/playlist.xsd">
+	<test>
+		<testCaseName>churn</testCaseName>


Suggest calling it churnGC_5min and creating a 2nd testTargetName called churnGC_4hr and setting the DURATION accordingly for both.

smlambert · 2024-02-26T18:21:01Z

functional/churn/playlist.xml

+		</groups>
+	</test>
+	<test>
+		<testCaseName>churn-nocoops</testCaseName>


We already have a mechanism to automatically run all test targets twice, once with compressedrefs JVM option, and a second time as noncompressedrefs JVM option.

I have to look closer at what NOCOMP does in the churn code, is it used for other decision-making within the test code to best advise.

it is propagating it to the logs name on top level - https://github.com/rh-openjdk/churn/blob/master/run.sh#L155, and setting the appropriate flags on the low level - https://github.com/rh-openjdk/churn/blob/master/bin/nocoops.sh

functional/churn/playlist.xml

judovana · 2024-02-26T18:44:08Z

TYVM! will elaborate tomorrow morning CET.

judovana · 2024-02-27T09:51:25Z

* the site generates archive full of logs, which are sueprusefull in case of failure. How to propagate them? Or maybe it is done correctly? If so how to see them in grinder?-)

It seems I'm handling resutls correctly. The only disadvantage of run in grinder is, that logs got packed second time. I will fix this in the usptream runner.

judovana · 2024-02-27T14:31:02Z

Hello! Bit more bussy day then expected:(

I had remvoed the disbaled coompressed ops variant, and left it to the framework to deal with it. If you would guide me a bit more, I will adjsut upstream to honor your setup I believe
I had renamed the targets and split them as you suggested
the results seems correct now
answer to iminent question is that it will fail ig the GC is msising, or not test, if there is additional GC. Any suggestion on the vendors which gamble so much with GCs? Simialrly with default GC.
- Currently the decision is based simply on jdk major version, I can add more, or add some custom wrapper
- Somethng like 050fb07 may work???? (I really am not sure...)
Similarly as I'm generating junit xml, it should be easy to generate tap files. Any ideas on it?

smlambert · 2024-02-28T04:21:03Z

re: #5101 (comment) - great, chat with you tomorrow about final steps

judovana · 2024-02-28T15:41:46Z

pls do not merge (yet). The 050fb07 is missbehavg in my test setup. But maybe my testsetup is wrong

smlambert · 2024-02-28T15:44:42Z

re: #5101 (comment) - I will convert this to Draft state, until all reviews and testing is completed (that way it can not get merged prematurely)

judovana · 2024-02-28T18:13:10Z

The 050fb07 , overwritten as 2249bc0 now works.

Am now updating readme to reflect the state. Will lift draft (thanx for setting it up) once done

Two new questions

the suite now generates next to jtreg archive also nice tap file. Is any special step needed to make it visible?
- https://ci.adoptium.net/view/Test_grinder/job/Grinder/8994/ do not publish them
if any GC fails, or (in case of churn_custom) user put in ninsense, it will make the job red.
- Is it ok, or should some other logic be added, to make it unstable?
Will this suite ( I guess the churn_5h_allGCs target) be part of any regular aqa runs in public jenkins?
- if so, to which, if not by default, but is desired can I add it somewhere?

judovana · 2024-02-28T18:14:24Z

The 050fb07 , overwritten as 2249bc0 now works.

Am now updating readme to reflect the state. Will lift draft (thanx for setting it up) once done

Two new questions
* the suite now generates next to jtreg archive also nice tap file. Is any special step needed to make it visible?
  
  * https://ci.adoptium.net/view/Test_grinder/job/Grinder/8994/ do not publish them

hmm.. https://ci.adoptium.net/view/Test_grinder/job/Grinder/8994/tapResults/ they are here! thoughts? I'm not sure what I did... (search for churn.tap or for eg shenandoah)

smlambert · 2024-02-28T19:01:33Z

re: #5101 (comment) - you did not need to do anything, our test pipelines always generate TAP files that include all test targets ( all <test><testCaseName> ... </test> entries defined in playlists). It is a feature of our TKG layer to create the TAP file, and a feature of our Jenkins groovy scripts to then attach the TAP files to the Jenkins job as an artifact.

smlambert

Review comments and suggestions are added inline

smlambert · 2024-02-28T19:13:29Z

functional/churn/playlist.xml

+		<command> 
+            export OTOOL_JDK_VERSION="$(JDK_VERSION)" ; \
+            export JREJDK="jdk" ; \
+            export OTOOL_garbageCollector="${CHURN_GCS}" ; \


Suggested change

export OTOOL_garbageCollector="${CHURN_GCS}" ; \

export OTOOL_garbageCollector="${APPLICATION_OPTIONS}" ; \

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 ?

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?

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.

functional/churn/README.md

smlambert · 2024-02-28T19:19:21Z

functional/churn/README.md

+
+## Running via aqavit
+
+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.


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.

functional/churn/README.md

functional/churn/playlist.xml

functional/churn/README.md

smlambert · 2024-02-28T19:36:26Z

functional/churn/playlist.xml

+		</platformRequirementsList>
+		<groups>
+			<group>system</group>
+		</groups>


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>

smlambert · 2024-02-28T19:39:30Z

functional/churn/playlist.xml

+		</platformRequirementsList>
+		<groups>
+			<group>system</group>
+		</groups>


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

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?

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!!)

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).

functional/churn/playlist.xml

smlambert · 2024-02-28T19:52:47Z

if any GC fails, or (in case of churn_custom) user put in ninsense, it will make the job red.
Is it ok, or should some other logic be added, to make it unstable?

Yes, we will add this test target with a disable tag, since it is there to support development, it can be used in Grinder jobs, and will be skipped in automated / regular test runs.

Will this suite ( I guess the churn_5h_allGCs target) be part of any regular aqa runs in public jenkins?
if so, to which, if not by default, but is desired can I add it somewhere?

Yes, it will get run against our EA builds which get triggered whenever a new upstream tag is available (so approximately weekly for each JDK version). Since we are adding this into dev level, and system group, the 2 enabled test targets in your playlist, churn_1m_allGCs and churn_5h_allGCs, will get run in our *dev.system* test jobs. I have asked you to restrict the test targets to just eclipse and redhat vendors for now, as I do not want to impact other vendors test execution times and also do not think other vendors are shipping with Shenandoah enabled.

judovana · 2024-02-29T10:59:09Z

re: #5101 (comment) - you did not need to do anything, our test pipelines always generate TAP files that include all test targets ( all <test><testCaseName> ... </test> entries defined in playlists). It is a feature of our TKG layer to create the TAP file, and a feature of our Jenkins groovy scripts to then attach the TAP files to the Jenkins job as an artifact.

Well, yes. With all pros and cons. There is usually one tap file, which consider the whole testsuite as on test. Then find properly what really run/failed inside is quite a detective task(but most liekly it is lack of my insight). Where the one default generated tap file is awesome feature, the suites usually generates much better outputs, and should be allowed to publish it.

In this case, the tap file churn generates is pretty good, and as the tkg toolchain is picking up all taps, it is pretty usable (feel free to correct me, or tell me to not generate it).

judovana · 2024-02-29T12:12:23Z

if any GC fails, or (in case of churn_custom) user put in ninsense, it will make the job red.
Is it ok, or should some other logic be added, to make it unstable?

Yes, we will add this test target with a disable tag, since it is there to support development, it can be used in Grinder jobs, and will be skipped in automated / regular test runs.

Will this suite ( I guess the churn_5h_allGCs target) be part of any regular aqa runs in public jenkins?
if so, to which, if not by default, but is desired can I add it somewhere?

Yes, it will get run against our EA builds which get triggered whenever a new upstream tag is available (so approximately weekly for each JDK version). Since we are adding this into dev level, and system group, the 2 enabled test targets in your playlist, churn_1m_allGCs and churn_5h_allGCs, will get run in our *dev.system* test jobs.

Thanx!

I have asked you to restrict the test targets to just eclipse and redhat vendors for now, as I do not want to impact other vendors test execution times and also do not think other vendors are shipping with Shenandoah enabled.

IIRC, shenandoah is enabled everywhere except jdk8 by default, so they would need to manually disable it during build. But why would anybody disable best GC around?

In case of shenandoah, especially because of its 'not-present' in jdk8, I will make it more dynamic. I can exclude GCs from default list based on :XX listings Will elaborate. It do not need to block this PR, only once it is created, other vendors may be onboarded.

smlambert · 2024-02-29T12:46:36Z

It do not need to block this PR, only once it is created, other vendors may be onboarded.

Yes, my thought with all of my review comments was to get the PR in and then come back later to adjust after we have run it for a while at the project.

smlambert · 2024-02-29T12:48:56Z

There is usually one tap file, which consider the whole testsuite as on test. Then find properly what really run/failed inside is quite a detective task(but most liekly it is lack of my insight). Where the one default generated tap file is awesome feature, the suites usually generates much better outputs, and should be allowed to publish it. In this case, the tap file churn generates is pretty good, and as the tkg toolchain is picking up all taps, it is pretty usable (feel free to correct me, or tell me to not generate it).

The TAP file is produced to 'normalize' test results from all suites. Having TAP files that do something different moves us away from normalization. For more granular information, we would look to test suites producing some sort of JUnit style output and then also present that.

judovana · 2024-02-29T13:10:13Z

There is usually one tap file, which consider the whole testsuite as on test. Then find properly what really run/failed inside is quite a detective task(but most liekly it is lack of my insight). Where the one default generated tap file is awesome feature, the suites usually generates much better outputs, and should be allowed to publish it. In this case, the tap file churn generates is pretty good, and as the tkg toolchain is picking up all taps, it is pretty usable (feel free to correct me, or tell me to not generate it).

The TAP file is produced to 'normalize' test results from all suites. Having TAP files that do something different moves us away from normalization. For more granular information, we would look to test suites producing some sort of JUnit style output and then also present that.

I see. The churn generates both tap file and packed junit file. So Your recomndation is to stop generating tap file? (no problem on my side, only I liked it :) )

judovana · 2024-02-29T16:07:57Z

It do not need to block this PR, only once it is created, other vendors may be onboarded.

Yes, my thought with all of my review comments was to get the PR in and then come back later to adjust after we have run it for a while at the project.

Sure. Thank you very much! Highly appreciated.

I had followed you review everywhere except the CHURN_DURATION. How do you feel about it?
I think we may enable more venodrs, but it is up to you, the requested chnage is done
readme updated
custom tap is no longer geenrated (/me very sad)
GH actions are passing all three OSes. But it is msys2 for windows on them, in grinder it is cygwin, and it fails there. Thoughts?
no mac run finished up to now (still waiting for executor).
- thus saying, I would :

 		<platformRequirementsList>
 			<platformRequirements>os.linux</platformRequirements>
-			<platformRequirements>os.win</platformRequirements>
-			<platformRequirements>os.osx</platformRequirements>
 		</platformRequirementsList>

wdyt?

Do you se enay more obstacles?

sophia-guo · 2024-02-29T16:58:29Z

The tests might need to move to system/ folder instead of functional/ folder if we'd like to trigger the tests automatically as part of jenkins test builds of dev.system. It does work in grinder under functional/ folder as in grinder we can manually set buildList=functional/churn, however in jenkins dev.system jobs buildList=system.

sophia-guo · 2024-02-29T17:08:16Z

functional/churn/playlist.xml

+-->
+<playlist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../TKG/resources/playlist.xsd">
+	<test>
+		<testCaseName>churn_1m_allGCs</testCaseName>


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

smlambert · 2024-02-29T17:09:05Z

The tests might need to move to system/ folder instead of functional/ folder if we'd like to trigger the tests automatically as part of jenkins test builds of dev.system. It does work in grinder under functional/ folder as in grinder we can manually set buildList=functional/churn, however in jenkins dev.system jobs buildList=system.

Good catch, we started off with this in functional group, but because it is a stress/load test, it is more appropriate to add it to system, so better to shift the churn folder into the system folder. +1

sophia-guo · 2024-02-29T17:13:41Z

GH actions are passing all three OSes. But it is msys2 for windows on them, in grinder it is cygwin, and it fails there. Thoughts?

Does the test require MVN? The output says 07:15:38 + which mvn 07:15:38 which: no mvn so no classes generated and failed.

judovana · 2024-02-29T17:47:45Z

GH actions are passing all three OSes. But it is msys2 for windows on them, in grinder it is cygwin, and it fails there. Thoughts?

Does the test require MVN? The output says 07:15:38 + which mvn 07:15:38 which: no mvn so no classes generated and failed.

Default build system is maven. But if it is not found, javac would do. So that is this case, it is compiled directly by javac.

sophia-guo · 2024-02-29T19:08:54Z

I see. It's an issue with window path and cygwin path.

+ E:/workspace/Grinder/jdkbinary/j2sdk-image/bin/javac -d /cygdrive/e/workspace/Grinder/aqa-tests/functional/churn/churn/target/classes ./org/jboss/churn/LogHistogram.java ./org/jboss/churn/TestRunner.java ./org/jboss/churn/WorkItem.java ./org/jboss/churn/WorkItemMap.java
07:15:40  + pushd /cygdrive/e/workspace/Grinder/aqa-tests/functional/churn/churn/target/classes
07:15:40  E:/workspace/Grinder/aqa-tests/\functional\churn\churn\run.sh: line 183: pushd: /cygdrive/e/workspace/Grinder/aqa-tests/functional/churn/churn/target/classes: No such file or directory

sophia-guo · 2024-02-29T19:26:35Z

For cygwin "$OS" =~ CYGWIN* you might need to use cygpth -w to print Windows form of directory of /cygdrive/e/workspace/Grinder/aqa-tests/functional/churn/churn/target/classes and also for any other cygwin paths.

sophia-guo · 2024-02-29T20:20:57Z

Mac looks good https://ci.adoptium.net/view/Test_grinder/job/Grinder/9033/console

hopefully all s/functional/system/g done properly

judovana · 2024-03-01T11:41:33Z

For cygwin "$OS" =~ CYGWIN* you might need to use cygpth -w to print Windows form of directory of /cygdrive/e/workspace/Grinder/aqa-tests/functional/churn/churn/target/classes and also for any other cygwin paths.

Right yiou are, rh-openjdk/churn#24 was all waht was needed. Rerunning windows.
Thanx a lot for info of mack! saved me some search :)

judovana · 2024-03-01T11:51:53Z

It do not need to block this PR, only once it is created, other vendors may be onboarded.

Yes, my thought with all of my review comments was to get the PR in and then come back later to adjust after we have run it for a while at the project.

Sure. Thank you very much! Highly appreciated.

* I had followed you review everywhere except the CHURN_DURATION. How do you feel about it?

* I think we may enable more venodrs, but it is up to you, the requested chnage is done

* readme updated

* custom tap is no longer geenrated (/me very sad)

* GH actions are passing all three OSes. But it is msys2 for windows on them, in grinder it is cygwin, and it [fails](https://ci.adoptium.net/view/Test_grinder/job/Grinder/9034/tapResults/) there. Thoughts?

* no mac run finished up to now (still waiting for executor).
  
  * thus saying, I would :

 		<platformRequirementsList>
 			<platformRequirements>os.linux</platformRequirements>
-			<platformRequirements>os.win</platformRequirements>
-			<platformRequirements>os.osx</platformRequirements>
 		</platformRequirementsList>

^ no longer necessary.

wdyt?

Do you se enay more obstacles?

I guess the disable of churn_custom target will happen as last thing in this commit once everything else is tunned

sophia-guo · 2024-03-01T14:11:02Z

Rerunning windows.

The new failure was related with migration from functional to system, I'm hitting the same issue with reproducible comparing tests. I can take a look next Monday.

judovana · 2024-03-01T14:40:30Z

Gosh. Rerunning windows here: https://ci.adoptium.net/view/Test_grinder/job/Grinder/9038/ green!
mac: https://ci.adoptium.net/view/Test_grinder/job/Grinder/9039/ green!
linux: https://ci.adoptium.net/view/Test_grinder/job/Grinder/9040/ green!

judovana · 2024-03-02T12:51:05Z

@sophia-guo TY!
@smlambert one approval reached, do you have any more hints?

sophia-guo · 2024-03-04T15:59:48Z

system/churn/build.xml

+		<mkdir dir="${DEST}"/>
+	</target>
+
+	<target name="dist" depends="getChurn" description="generate the distribution">


Should add init task as depends depends="getChurn, init" unless the non-exist directory will be created when doing the <copy todir="${DEST}">? Not sure about this looking at the grinder the $DEST was created.

smlambert

thanks @judovana ! I may come back for an enhancement on how we run the churn_custom target, but this is good as is.

smlambert · 2024-02-29T16:16:58Z

functional/churn/playlist.xml

+		</platformRequirementsList>
+		<groups>
+			<group>system</group>
+		</groups>


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).

judovana added 3 commits February 26, 2024 18:32

Added churn testsuite

2833dee

instead of pushd, moved to results dir pernamently

f6fa4df

Added second set of tests - without compressed oops

517b988

smlambert requested changes Feb 26, 2024

View reviewed changes

judovana added 2 commits February 26, 2024 19:46

Moved to system group

e7c6f7c

Adjusted description

3dc815d

judovana added 3 commits February 27, 2024 14:44

Removed NOCOMP=-nocoops variant in favour of global setting

4db1633

split churn testsuit to churn_1m_all and churn_5h_all

550593a

added proper quoting

655e499

judovana force-pushed the churn branch from 00dda3d to 655e499 Compare February 27, 2024 14:20

Onem ore rename of targets to churn_5h_allGCs and churn_1m_allGCs

1cc8542

smlambert marked this pull request as draft February 28, 2024 15:44

added custom churn testcase

2249bc0

judovana force-pushed the churn branch from 050fb07 to 2249bc0 Compare February 28, 2024 17:27

Updated README to proeprly describe churn_custom and extend it as needed

ec66f1a

judovana requested a review from smlambert February 28, 2024 18:37

judovana marked this pull request as ready for review February 28, 2024 18:38

smlambert requested changes Feb 28, 2024

View reviewed changes

Adapted readme

b69d963

smlambert requested a review from sophia-guo February 29, 2024 12:49

No longer generate tap files on automated runs

9684763

sophia-guo reviewed Feb 29, 2024

View reviewed changes

judovana added 2 commits March 1, 2024 10:25

moved churn to system

8826b5d

hopefully all s/functional/system/g done properly

Limited custom churn to 24h to not overwhel grinder

90ec5e7

sophia-guo approved these changes Mar 1, 2024

View reviewed changes

karianna requested a review from smlambert March 2, 2024 21:05

sophia-guo reviewed Mar 4, 2024

View reviewed changes

smlambert approved these changes Mar 4, 2024

View reviewed changes

smlambert merged commit 6f0d4bb into adoptium:master Mar 4, 2024
2 checks passed

smlambert mentioned this pull request Mar 5, 2024

AQAvit Community Call (March 5, 2024 edition) #5090

Closed

smlambert mentioned this pull request Mar 13, 2024

Adapted to most recent changes in churn - arguments support #5129

Merged

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


		## Running via aqavit

		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.

Added churn testsuite #5101

Added churn testsuite #5101

Conversation

judovana commented Feb 26, 2024

judovana commented Feb 26, 2024

smlambert left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

judovana commented Feb 26, 2024

judovana commented Feb 27, 2024

judovana commented Feb 27, 2024 • edited Loading

smlambert commented Feb 28, 2024

judovana commented Feb 28, 2024

smlambert commented Feb 28, 2024

judovana commented Feb 28, 2024

judovana commented Feb 28, 2024 • edited Loading

smlambert commented Feb 28, 2024

smlambert left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smlambert commented Feb 28, 2024

judovana commented Feb 29, 2024

judovana commented Feb 29, 2024

smlambert commented Feb 29, 2024 • edited Loading

smlambert commented Feb 29, 2024

judovana commented Feb 29, 2024

judovana commented Feb 29, 2024

sophia-guo commented Feb 29, 2024

Choose a reason for hiding this comment

smlambert commented Feb 29, 2024

sophia-guo commented Feb 29, 2024

judovana commented Feb 29, 2024

sophia-guo commented Feb 29, 2024 • edited Loading

sophia-guo commented Feb 29, 2024 • edited Loading

sophia-guo commented Feb 29, 2024

judovana commented Mar 1, 2024 • edited Loading

judovana commented Mar 1, 2024

sophia-guo commented Mar 1, 2024

judovana commented Mar 1, 2024 • edited Loading

judovana commented Mar 2, 2024

Choose a reason for hiding this comment

smlambert left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

judovana commented Feb 27, 2024 •

edited

Loading

judovana commented Feb 28, 2024 •

edited

Loading

smlambert commented Feb 29, 2024 •

edited

Loading

sophia-guo commented Feb 29, 2024 •

edited

Loading

sophia-guo commented Feb 29, 2024 •

edited

Loading

judovana commented Mar 1, 2024 •

edited

Loading

judovana commented Mar 1, 2024 •

edited

Loading