Re: Value types - compatibility with existing “value objects”

[Vitaly Davidovich]

I think some of that true.  For example, a lot of lock code looks like:

lock.lock();
try {
...
} finally {
 lock.unlock();
}

If the lock implementation causes SOE or OOM as part of lock() and yet
acquires the lock in the process, then yes, you're hosed.  This is a
quality of implementation issue.  Someone can also abort the thread right
after the lock is acquired but before you enter the try region.
Thankfully, people are discouraged from doing that and you don't tend to
see this in the wild.

In terms of finally blocks not being executed, I don't think that's true
(modulo JVM crashing) if the SOE was thrown from within a try/catch block.
The JVM intentionally reserves some space at the tail of the stack to leave
room for itself to initiate unwinding.




On Fri, Jan 9, 2015 at 9:01 AM, Simon Ochsenreither <simon at ochsenreither.de>
wrote:

> > Worth mentioning that SOE is infinitely more recoverable than heap OOME.
> >  In the latter case (especially with complex systems, where the risk is
> > ironically even higher of it happening) there's often not much you can
> > do other than kill off the JVM and try again.  But if you run out of
> > stack, everything should unwind in a very predictable (and fast) manner.
> >  You could even automatically rebuild your thread pools with larger
> > stack sizes fairly easily.
>
> Your VM might be broken after both. SOE is definitely not recoverable.
> Yes, it might work, but no guarantees it does.
>
> Money quote: "You will find occurrences of StackOverflowError leaving
> locks locked, monitors acquired, and "finally" block not invoked, even
> if JVM doesn't crash."
>
> Maybe things have changed since then?
>