[lworld] RFR: Unsafe primitives for values

[John Rose]

On Dec 13, 2018, at 1:14 AM, Roland Westrelin <rwestrel at redhat.com> wrote:
> 
> Hi Mandy,
> 
>> Your memory is correct and we went with the "Unsafe::withXXX" option 
>> initially.  John talked to me a couple weeks ago that he suggests to go 
>> with the "private buffer" option which is more robust than the "new 
>> withXXX API points, 10 of them (primitive + ref + value)". With the 
>> private buffer option, the existing Unsafe::putXXX APIs on the buffer 
>> will have predictable effects. The JIT can easily eliminate the 
>> allocation away the buffer.  John sketched the rough idea of this option 
>> [1].  I did prototype the withXXX option to get a sense of the usage of 
>> these new API points.  I do like this private buffer option better.
> 
> Thanks for the background info.
> 
> Roland.

Thanks, Mandy, for improving the record.  In the meeting you recalled
I verbally preferred the other option, basically after a mental coin flip.
Since then I've come to prefer the larval-buffer option because, although
it introduces an extra entity, this entity pays for itself by providing a very
stable and predictable model for all kinds of updates, not just ones which
adhere to the single-field "with" model.  So, for example, we are free to
model bulk copy of a 64-bit value type of several fields using a single
"long" update, if we can prove that the JVM has given it appropriate
layout and alignment.  More subtly, we can optimize substitutability
tests using bulk bit comparisons, with appropriate masking, if the
JVM reveals appropriate layout, type, and masking information.
The larval buffer approach also gives us more options for aliasing
value instances onto foreign and/or encapsulated memory (off-heap,
persistent memory, byte buffer contents, etc.).

Basically, revealing a value instance as a "passive" buffer of memory
gives us a bigger toolbox for working with value types, which pays
for the introduction of the larval buffer concept.  When it was just
a question of API surface for implementing things like serialization,
I thought it was a coin flip; now that I've had a chance to think more
about use cases, the coin is weighted.

Thanks very much, Roland, for working on this.

— John