P4
http://mail.openjdk.java.net/pipermail/jmh-dev/2014-June/001043.html
I just had a head-scratchy 30 minutes that could have been avoided if stack traces had been eagerly printed when an exception kills a thread that is part of a @Group (I haven’t checked if it’s the same for ordinary non-@Group worker threads).
I had accidentally put a ThreadLocalRandom.current().next(0) in one of my benchmark methods, right after taking a write lock on a StampedLock that I foolishly didn’t unlock in a finally-clause. The next(0) threw an exception and killed the thread, leaving the lock taken, while the other threads in the group quickly got stuck waiting for that lock. The exception from next(0) was never printed to my console for some reason, leaving me quite puzzled as to what was going on.
I just had a head-scratchy 30 minutes that could have been avoided if stack traces had been eagerly printed when an exception kills a thread that is part of a @Group (I haven’t checked if it’s the same for ordinary non-@Group worker threads).
I had accidentally put a ThreadLocalRandom.current().next(0) in one of my benchmark methods, right after taking a write lock on a StampedLock that I foolishly didn’t unlock in a finally-clause. The next(0) threw an exception and killed the thread, leaving the lock taken, while the other threads in the group quickly got stuck waiting for that lock. The exception from next(0) was never printed to my console for some reason, leaving me quite puzzled as to what was going on.