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

[John Rose]

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