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

[Vitaly Davidovich]

Great, happy to hear you guys are exploring that.  I can't tell you how
much code I've seen and written that's just ugly because people are
avoiding temp objects (e.g. pools, decomposing their would-be objects into
primitives and then passing them around as arguments, not using collection
iterators, using primitives and then adding a bunch of static methods to
"make sense" of it, etc).  There are lots of times I want to say "goddamit,
I know what I'm doing - stop holding my hand and let me out of this
sandbox!" :) Now, I know some of this comes with the territory but it just
feels like we can do better.  Value types have the potential to cure some
of this substantially, and that's why it's a subject I'm particularly
interested in (and I'm sure others as well).

As for abusing stack space and getting SOE, no issues in my opinion - I can
cure that without destroying the code.  But that should be the preferred
form of automatic storage management for ephemeral situations (and there
are lots of them) and leave the heap for stuff that has
unknown/long/shared/etc lifetime.  So again, happy that you guys are
exploring that.

Sent from my phone
On Jan 8, 2015 7:38 PM, "John Rose" <john.r.rose at oracle.com> 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!
>
>