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

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 9 12:10:07 UTC 2015


Stack space is usually reserved but not committed; this means your virtual
memory goes up but your resident/working set doesn't really (assuming not
every thread hits the same peak); on 64bit systems this is not an issue.
C/C++ programs use stack heavily, including allocating large temp buffers,
and I've yet to see anyone it's a problem (in fact, quite the opposite -
easy use of stack is one of the touted strengths of these languages when
these debates come up on various websites).

At any rate, nobody writing sane value types (even largish ones) will blow
their stack space.  You're more likely to do that via recursion, I think.

Sent from my phone
On Jan 9, 2015 2:15 AM, "Peter Levart" <peter.levart at gmail.com> wrote:

> 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
>
>


More information about the valhalla-dev mailing list