When an exception kills a thread in a Group

[Aleksey Shipilev]

On 06/25/2014 02:11 PM, Chris Vest wrote:
> This one is consistently getting stuck without printing stack traces for
> me (JMH 0.9):

Thanks, my original hunch was almost correct. The exceptional thread
indeed exits, and the second thread is stuck at StampedLock acquire. The
*control* thread which reads the results from the benchmark threads
(through the futures), waits for synchronize iteration epilog to finish,
which will never finish since second thread is stuck.

This touches on a sophisticated mechanics of sync iterations, exception
propagation, and interrupts, and that can be bullet-proofed a bit later.
Eagerly printing the exceptions does not solve the problem of
misbehaving benchmarks: humans can certainly Ctrl-C the run, but larger
suites should recover automatically.

Your test, on other hand, fails with proper exception if you follow the
rules for using locks and wrapping them with try-finally: in that case,
second thread will be unblocked, all results would be collected, and the
deferred exception would fire up.

Thanks,
-Aleksey.