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

[Dariusz Jędrzejczyk]

I recently encountered an issue (using 0.15) that only surfaces using
an M1 aarch64 JDK (both BellSoft Liberica and Azul).
My JCStress tests are causing a java.lang.OutOfMemoryError: unable to
create new native thread, only on ARM dedicated JVM builds.
Specifically I'm using:
- OpenJDK 64-Bit Server VM (Zulu 8.66.0.15-CA-macos-aarch64) (build
25.352-b08, mixed mode) (Azul)
- OpenJDK 64-Bit Server VM (build 25.352-b08, mixed mode) (BellSoft Liberica)
When using an x86 JDK by Temurin (OpenJDK 64-Bit Server VM
(Temurin)(build 25.332-b09, mixed mode)) (using Rosetta as I
understand) the same scenario passes.

My observation is that when the generated body for
org.openjdk.jcstress.infra.runners.Runner#internalRun implementation
enforces the time limit on the CounterThread instances, it possibly
leaves garbage in the form of initialized @State objects of the tests
and the user has no way to perform cleanup. My strategy here was to
initialize the object in the instance init block and perform cleanup
either in the @Actor or @Arbiter methods. However, upon timeout, the
private method {MyTestClass}_jcstress#jcstress_consume will
re-initialize the objects for the next stride sequence, but will not
call any methods and exit. The next iteration will then have the
impact of those objects lying around (unless GC collects them).

Below is the most simplistic code I was able to come up with that
reflects my scenario. In my actual workflow I'm validating proper
cleanup of a resource. The resource under test starts an evictor
thread upon initialization, so I'm also validating that it is properly
released as part of the racing cleanup.

@JCStressTest
@Outcome(id = {"true"}, expect = Expect.ACCEPTABLE, desc = "All Good.")
@State
public static class ThreadStressTest {
   private final CountDownLatch latch = new CountDownLatch(2);
   private final Thread t = new Thread(() -> {
      try {
         latch.await();
      } catch (InterruptedException e) {
         throw new RuntimeException(e);
      }
   });

   {
      t.setDaemon(true);
      t.start();
   }

   @Actor
   public void countDown1(Z_Result r) {
      latch.countDown();
      try {
         latch.await();
      } catch (InterruptedException e) {
         throw new RuntimeException(e);
      }
   }

   @Actor
   public void countDown2(Z_Result r) {
      latch.countDown();
      try {
         latch.await();
      } catch (InterruptedException e) {
         throw new RuntimeException(e);
      }
   }

   @Arbiter
   public void arbiter(Z_Result r) {
      try {
         r.r1 = latch.await(100, TimeUnit.MILLISECONDS);
      } catch (InterruptedException e) {
         throw new RuntimeException(e);
      }
   }
}

If in the above example, the thread is started lazily by one of the
actors, the issue does not occur, which makes sense after analyzing
the generated source code that JCStress produces.
There is no problem when run with just 1 iteration - that again makes
sense, as the initial estimation of the number of strides prepares for
not blowing up the environment. However when there are more
iterations, the leftover objects are not taken into account by the
initial evaluation.

Thanks in advance for any comments. I'd be really keen to know whether
x86 JDK not failing is expected or rather there are some measures
taken in JCStress to clean up the leftovers that the ARM version does
not exercise properly.
As a way to overcome this issue completely, would it be feasible to
initialize resources at the beginning of the stride loop instead of at
the end of it to prevent garbage generation completely? An alternative
would be to provide a hook for teardown, but JCStress would need to
call it in all cases, even when it times out.

Thanks in advance.
Dariusz Jędrzejczyk