Value-based classes in jdk.incubator.foreign

[Maurizio Cimadamore]

On 25/11/2020 14:27, Jorn Vernee wrote:
> I think we might want to re-evaluate if it's worth it to rotate these 
> classes to being primitive classes as well (since this does introduce 
> restrictions).
>
> e.g. the potential gains for MemorySegment seem much more obvious to 
> me, since those typically are created and accessed in hot loops, while 
> MemoryLayouts are more typically declared once as a static final 
> field, and then only accessed to create var handles which are again 
> stored in static final fields (or do we expect much heavier churn with 
> MemoryLayouts in the future?). The potential gain doesn't seem to be 
> that big for MemoryLayouts.

In a way I agree with you  - at the same time right now out Layout does 
provide few transforming operations like MemoryLayout::map and 
SequenceLayout::flatten/reshape which could benefit from the value 
treatment. In other words, as soon as you write something that's doing 
some manipulation over layouts (and with variable-length data this might 
be more common), I suspect that the cost of instantiating them is gonna 
show up more. So, yes, it's a bit on the fence, but at the same time 
none of the restrictions added seems to me as a real deal breaker, so 
I'd prefer to keep the option open?

Maurizio

>
> Jorn
>
> On 24/11/2020 23:18, Maurizio Cimadamore wrote:
>> That's all good - thanks for the headsup.
>>
>> I think, as I commented elsewhere, some of the issues with the 
>> current hierarchy in the foreign memory access API stem from 
>> transient choices (such as that of using a stateful intermediate 
>> class for layouts). I think that, moving forward, we can easily 
>> adhere to the final value-based specification.
>>
>> Maurizio
>>
>> On 24/11/2020 19:38, Dan Smith wrote:
>>> JEP 390 has done some work to reconcile the "value-based class" 
>>> concept in JDK APIs with future primitive classes, as being designed 
>>> in Valhalla.
>>>
>>> One conclusion we reached is that it will not be helpful in the 
>>> future to have distinct "value-based" and "primitive" properties for 
>>> classes; the former should be superseded by the latter. A class 
>>> should either be designated value-based, with the intent to 
>>> eventually become a primitive class, or it should just avoid the 
>>> "value-based" terminology and state directly whatever properties it 
>>> wishes to advertise.
>>>
>>> This has led to a revised definition of value-based class, which, 
>>> among other things, asserts that the class is final and the 
>>> superclass declares no instance fields. See here:
>>>
>>> https://github.com/openjdk/valhalla/pull/222/files#diff-5b3f533129ebe96efc9d6d51a4bdf33b56dc8aa0586343c792621ebcbd4fb77e 
>>>
>>>
>>> This creates some problems for classes in jdk.incubator.foreign:
>>>
>>> - Implementations of MemorySegment are supposed to be value-based, 
>>> but are non-final and inherit fields.
>>>
>>> - Subclasses of AbstractLayout claim to be value-based but inherit 
>>> fields
>>>
>>> For now, I've left the "this is a value-based class" comments in the 
>>> javadoc, with some revisions in the boilerplate text.
>>>
>>> https://github.com/openjdk/valhalla/pull/222/files#diff-11d74c4a0e74adb54334cb36c0e5e71fd9e2ab95269412cb3e040d8ce80d9726 
>>>
>>>
>>> If the intent is to eventually migrate these to be primitive 
>>> classes, their hierarchies should be adjusted to satisfy the 
>>> requirements. If not, we should remove the references to value-based 
>>> classes.