Value types - compatibility with existing “value objects”

[Peter Levart]

On 01/09/2015 06:52 AM, David Holmes wrote:
> On 9/01/2015 11:57 AM, David M. Lloyd 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> 
>>> 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.
>
> 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.
>
> David H.
>

Another point to consider is that heap is shared among all threads and 
stack space is allocated per-thread. If peak stack utilization increases 
with value types in some threads and as a consequence user increases 
max. stack size for the whole JVM, a lot of space is wasted in many 
threads that don't need that much stack space. There are various 
trade-offs here.

Peter