Value-based classes in jdk.incubator.foreign

[Jorn Vernee]

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.

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.