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

[Vitaly Davidovich]

I've seen this too, but only a handful of times.  For all practical
purposes, it's very difficult to write a java program that's hardened
against memory exhaustion (this is arguably where something like C has it
easier), heap or stack.

Sent from my phone
On Jan 9, 2015 12:52 AM, "David Holmes" <david.holmes at oracle.com> 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.
>
>