Value-based classes in jdk.incubator.foreign

[John Rose]

If you are able to define a new class as primitive, and are
sure you won’t want to migrate it back later to have
identity (state), then I don’t see many reasons *not* to
define it as primitive.  If you want migration options
and/or polymorphism, then an interface with a backing
primitive implementation is good.  When the JIT sees
a static-final constant, and notes that the value is a
primitive (whether or not the declared type was “obscure”)
it can do a better job with that than with an identity class.

— John

> On Nov 25, 2020, at 7:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 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.