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

Vitaly Davidovich vitalyd at
Fri Jan 9 03:01:17 UTC 2015

Silly but easy to see (I think) example: infinite recursion via method
calling itself, no tail call optimization, and each invocation of this
method mutates something that outlives this thread.  JVM won't throw SOE
until it bumps into the yellow zone (I think it's the yellow where the red
is reserved for itself to have room to handle java SOE) and can't expand
the stack any further.

Sent from my phone
On Jan 8, 2015 9:48 PM, "David M. Lloyd" <david.lloyd at> wrote:

> I'm admittedly no expert on such things, but I'd hope that my method would
> never be entered unless there was stack space enough for its whole
> execution frame.
> On 01/08/2015 08:02 PM, Vitaly Davidovich wrote:
>> I'm not sure that's true - what if right before the stack is expanded
>> some mutation is performed that isn't undone upon SOE? I'd say both OOME
>> and SOE are the types of "async" exceptions that are hard to recover from.
>> I do, however, think it's easier to track down the cause of SOE than a
>> heap OOME since you have one call stack to inspect whereas you may hit a
>> heap OOME purely being a victim of someone else polluting it.
>> Sent from my phone
>> On Jan 8, 2015 8:57 PM, "David M. Lloyd" <david.lloyd at
>> <mailto:david.lloyd at>> wrote:
>>     On 01/08/2015 06:37 PM, John Rose wrote:
>>         On Jan 8, 2015, at 4:29 PM, Vitaly Davidovich <vitalyd at
>>         <mailto:vitalyd at>> wrote:
>>             Thanks John.  I read that paragraph just now and do see
>>             mention of spilling to heap.  However, the bulk of the
>>             paragraph talks about the intended use of value types, which
>>             I fully agree with.  The register file is just an example of
>>             how one can best achieve performance by scalarizing the
>>             value type across registers - great, love it! However, I
>>             don't quite understand why you need to spill to heap and not
>>             restrict it to stack only.  I know this is probably
>>             discussing a pathological case as I'd imagine the threshold
>>             you pick will not be hit by people actually writing
>>             performant code, so perhaps we don't need to discuss it at
>>             length.
>>             In terms of freedom of implementation,  another thing I
>>             highly agree with.  However, I'd like to have a bit more
>>             control in some cases.  There are things the VM does that
>>             either I can't do reasonably or at all and I appreciate that
>>             (e.g. the various JIT optimizations around devirtualization
>>             as just one example).  But, for some things I'd like to have
>>             more say :).  Storage is one of them.  I'm sure you guys
>>             know that there are people out there that either avoid the
>>             GC like a plague and/or take their data offheap.  Using
>>             stack for temps is almost always going to be preferred over
>>             heap.  Anything that we can do to facilitate that would be
>>             fantastic.  Automatic storage is great when it's warranted,
>>             but it's a big hammer in some situations.
>>             P.S. I think GC still doesn't sit well with certain groups
>>             of people, thus some excitement about new languages like
>>             Rust and criticism of others (e.g. Go, D) that have it.
>>             Obviously I'm not saying java needs to abandon it, but there
>>             are folks building middleware/infra components where they'd
>>             like better facilities.
>>         Thanks for the good comments, Vitaly.  Yes, GC is a key
>>         value-add, and requires a whole team to keep fresh.
>>         Indeed we are looking at managing stack more cleverly also.  A
>>         warning note:  If you OOME by moving stuff onto stack, you
>>         increase the frequency of SOE!
>>     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.
>>     --
>>     - DML
> --
> - DML

More information about the valhalla-dev mailing list