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