Value types - compatibility with existing “value objects”

[David Holmes]

On 10/01/2015 12:01 AM, Simon Ochsenreither 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."

"Locks locked" is true for ReeentrantLock because an unlock can throw 
SOE when trying to set the owner to null - this leaves the lock 
"unlocked" but with an apparent owner and so no lock() will then 
succeed. This is a telling example of how SOE can result in broken 
invariants, and there is no simple fix.

It is not true for monitors or finally blocks. Of course if the finally 
block contains a call then it too could trigger a secondary SOE.

> Maybe things have changed since then?

Since when? I've never known it to be true for monitors or finally blocks.

David