vwithfield and ValueType.findWither

[John Rose]

On Jun 15, 2017, at 2:36 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> On 15/06/17 09:46, John Rose wrote:
>> On Jun 14, 2017, at 2:20 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>> Another possible story is that we always create values through the VCC constructor, and then unbox. If we think we're happy with that, that might be a fine choice too.
>> That's not a bad story for the JIT with aggressive scalarization,
>> and was my first idea about this, but it is painful in the interpreter.
>> 
> In which ways it's bad for the interpreter? Note that the current implementation of the 'modified' findWither will do just that:
> 
> * box incoming value
> * set field (with Unsafe.putXYZ)
> * unbox resulting reference back to a value
> 
> So, it seems to me that, to set 5 fields, the above idiom will do box/unbox 5 times, while if we just create a VCC with the fields we want and then unbox, that's just one unboxing step.
> 
> What am I missing?


You're not missing anything.  Making a VCC will be an easy thing
to do, since the VCC will have lots of method machinery and
(IIRC) even constructors.

My concern is for other kinds of code, outside the VCC, which uses
compositions containing withers to build values, using MH's.

Recycling boxes is really treating them as local scratch buffers.
Because object identity is stable, we can rely on the JVM not confusing
side-effects to box objects (a rare win for object identity).  And the JIT
should elide the buffer (box object) using escape analysis.  So all is
good there.

And the standard idiom a constructor on a POJO with final fields
fits perfectly here, where the VCC is the POJO.  (We can port
such source code directly to the full value types world.)

The fly in the ointment, I think, is that if you take one step away from
the multi-use buffer, you find that you are composing wither MH's
into a MH graph.  Each wither will have to make its own buffer;
there seems to be no way to encourage them to share.  This means
that the interpreter will see five separate heap allocations in your
example.  The JIT will see them too, and collapse them.  The JIT
would prefer that there is one shared box, just because code volume
matters.