Value types - compatibility with existing “value objects”

[David M. Lloyd]

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 redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     On 01/08/2015 06:37 PM, John Rose wrote:
>
>         On Jan 8, 2015, at 4:29 PM, Vitaly Davidovich <vitalyd at gmail.com
>         <mailto:vitalyd at gmail.com>> 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