Iterations initialize @State objects and don't provide a way to clean up

[Dariusz Jędrzejczyk]

> I am not sure what timeouts have to do with it. Do you mean "once iteration time expires, we leave
> the last stride unprocessed"? Because the actual timeout, as in "test method did not return", the
> harness would assume the worst and terminate the VM, thus cleaning up the resources.

I did mean the former, the iteration duration being reached, apologies
for using imprecise terms.

> Please try this PR, if you can:
>    https://github.com/openjdk/jcstress/pull/124

Works like a charm on ARM JDK17. When I use JDK8 however, the issue
still keeps happening. I needed to change the source and target
versions in pom.xml of the samples module to 1.8 and run as other
examples (adding -m default helps).

Thank you for the PR. I thought this would solve the issues I've been
observing, as it apparently does perform the cleanup that was missing.

My curiosity still remains - do you have an idea why in the case of
x86 JDK the issue did not show up? Is there some sort of OOM killer
mechanism implemented? Are daemon threads without a reference to them
somehow natively terminated once a thread limit is about to be
reached? Knowing the actual conditions better now, I'm more surprised
my tests did not fail on x86 -> the ARM JDK looks like it's running
into the issue as expected.

Thanks in advance Aleksey if you find a spare few mins to explain if
you know what's going on. I have not succeeded in reproducing the
graceful outcome without JCStress - any accumulation of daemon threads
leads to reaching the limit and consistent failure.

Let me know if I should prepare a fork with my changes to help
reproduce the issue on your setup.

Best,
Dariusz