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

[Aleksey Shipilev]

Hi,

On 11/9/22 11:42, Dariusz Jędrzejczyk wrote:
> 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).

Right, so this is arguably the state lifecycle problem. I think it is a reasonable expectation to 
have the state object processed once it was created, which allows using @Arbiter as faux-cleanup method.

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

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.

There is a minor secondary bug, though, indeed: once we finish internalRun() in one way or the 
other, we should really be cleaning up the leftover state/result arrays without waiting for new 
iteration, which might never come. I shall deal with that too.

-- 
Thanks,
-Aleksey