Value types - compatibility with existing “value objects”

[David M. Lloyd]

On 01/08/2015 11:52 PM, David Holmes wrote:
> On 9/01/2015 11:57 AM, David M. Lloyd 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.
>
> Going OT but I strongly disagree. At least people try to write code that
> accounts for potential OOME for explicit allocation sites (eg allocate
> first then modify local state that affects invariants). I've never seen
> any code that anticipates that any call might trigger a SOE.

I agree that not much code *does* account for SOE.  But, it's often 
(usually? always?) *possible* to do so, as opposed to OOME due to (say) 
GC overhead which is nearly always a complete failure condition for the 
JVM (allocating, say, a single big array is really not the common case 
here IMO).  An SOE doesn't affect the functionality of the JVM outside 
of the thread that experiences it the way that your typical OOME does.

Also, having never personally experienced incorrect program operation 
due to SOE (as opposed to having experienced various JVM failures due to 
OOME on many occasions), I'm willing to broadly say that it's usually 
not a problem in practice, even if few (if any) programmers actively try 
to account for it.

-- 
- DML