make jcstress default targets enabled:

[judovana]

• I do not see the aarch64 failures as adoptium see
• there is weird oscilation of NUMBER of tests between windows, ppc64le, aarch64 and x86_64
• That is folowed by time oscialtions (http://****:8080/search/?q=-B1t2%253A+jcstress)
  • windows aprox 11 hours (all on vagrant)
    • tests 3534, test cases 42408 tests in all variants
      • quite a few soft (api mishmash) errors
  • aarch64 1-3days, avarage in 1.2 days (depending on HW)
    • tests 3534, test cases 168840 tests in all variants
  • ppc64le 1-3days, avarage in 1.5 days (depending on HW)
    • tests 3534, test cases 168840 tests in all variants
  • x86_64 1-3days, avarage in 2 days (depending on HW)
    • tests 3534, test cases 84420 tests in all variants
• (on linuxes, the 84420 x 168840 seesm to be oscilating, probably due to some CPU setup, obviously it is making the jumping the time from x->x2->(x2)/2...)
• I had locally implemented conversion of jcstress resutls to junit.xml
  • this must be usptreamed (together with 5more issues I found in meantime:
  • CODETOOLS-7903818 jcstress do not print structuralised results
  • CODETOOLS-7903754 jcstress should die asap - with report - on broken jvm/hw, instead of waiting on kill
  • CODETOOLS-7903774 make all tests combinations printing nicer and/or configurable
  • CODETOOLS-7903766 affinity detected but later marked as invalid argument
  • CODETOOLS-7903750 TimeBudget (-tb) does not fulfill its promisses

Thougts?

[smlambert]

We will not enable jcstress tests in our regular test runs at the project as we are conserving our machine resources.

Other vendors are welcome to run the disabled targets, or enable on a per vendor basis.

Given our constraints, but also that vendors are not constrained, I would leave this issue open temporarily for a week or so for others awareness, then close as won't fix.

[judovana]

Yah, From the results i posted, I was thinking the same. I agree for sure with what you wrote, just few thoughts I would like to understand better:

• what is your (well anybody/general) requirement to enable it (specifically it)?
• aren't you concern with the aarch64 failures we saw on gridner ?

[smlambert]

what is your (well anybody/general) requirement to enable it (specifically it)?

In my opinion, these tests are good for testing GC changes in the upstream repo, so my inclination would be that GC devs would run these when testing new GC features or major changes (via Trestle pipeline). They could additionally be run on a not very often schedule or against tagged releases, but considered 'blocking' or 'required' tests (run in order to fill the gaps between times where they are run as part of developer testing).

aren't you concern with the aarch64 failures we saw on grinder ?

Being concerned and having the human resources / time to investigate are 2 different matters. Should there be resources, I would start them off by looking at profile of the test nodes (how the configuration of the machines differ, etc) as I am certain there would be many differences.

[judovana]

Fair enough. Issue done by me. TY!