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

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 9 00:29:39 UTC 2015


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.

Sent from my phone
On Jan 8, 2015 7:07 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Jan 8, 2015, at 8:59 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> I am not sure where you got this idea that somehow "too big" values would
> require a different syntax.  However, its possible you're running on a
> machine with a very restricted register set, and a 4x4 matrix of longs is
> too big to pass by value, so it gets silently boxed, and you don't get all
> the performance you get with a 2x2 matrix.  But this is no different from
> any other hardware effect (size or number of cache lines, etc.)
>
>
>
> Why is # of registers a factor here? I'd expect some # of registers to be
> used for passing some of the values (depending on calling convention), and
> the rest passed on the stack.
>
>
> The values proposal touches on these points; see the paragraph beginning
> like this:
>
> A "soft" restriction on values is that they are "not too large".
>
> http://cr.openjdk.java.net/~jrose/values/values-0.html
>
> This is also the first I hear of VM reserving the right to transparently
> box depending on some size threshold.
>
>
> Most of us have moments of surprise at what the VMs does!  As Brian says,
> they have virtual instruction semantics to implement on the users behalf,
> and lots of freedom how to make it work.
>
> My preference would be to simply use
> the stack, and if you run out of stack, handle that the same way as today.
> Clearly someone passing a giant value type around is not doing themselves
> any good, but the automagic boxing behind the scenes doesn't sit well.
>
>
> There was a time before Java was widespread, when automatic storage
> management didn't "sit well" with most C/C++ programmers.  (Perhaps it
> still doesn't, though now there is Boehm GC, etc.)  In our present world,
> VMs manage storage automatically.  A necessary cost of this is occasional
> errors when resources are exhausted.
>
> What if boxing that giant value type causes an OOM? I don't think that
> would be expected.
>
>
> It depends on what you mean by "expected", but part of the agreement
> between users and VMs is that the JVM is allowed to throw certain errors
> (subtype of VMError) when its automatic tactics fail.  Such errors are
> rarely expected, except in the sense that you can expect the VM to throw
> such an error where other kinds of programs will crash or execute
> unpredictable paths through hand-written recovery code.
>
> See JVMS 6.3, 2.5.[23456], and 5.4 for a discussion of VM errors.
>
> We know there are users who work very hard to tweak their code to exclude
> such errors.  It is a difficult task, since they are tweaking for behaviors
> that are not guaranteed by the spec., but are provided by the good
> qualities of a particular JVM implementation.  JVM implementation and
> optimization techniques change over time, and you can expect behaviors to
> change along with them (staying in-spec), including subtle shifts in where
> the "red line" of resource exhaustion is for any given JVM workload.
>
> — John
>


More information about the valhalla-dev mailing list