Value types - compatibility with existing “value objects”
david.holmes at oracle.com
Mon Jan 12 04:36:10 UTC 2015
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.
More information about the valhalla-dev