Value types - compatibility with existing “value objects”
David M. Lloyd
david.lloyd at redhat.com
Fri Jan 9 14:08:08 UTC 2015
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.
More information about the valhalla-dev