EG meeting, 2021-11-17

[Dan Heidinga]

>> > For the moment I think this does probably carry over to WithIdentity/WithoutIdentity or whatever they are called. The question I think is still open (to me) is whether there really are active contractual implications of being identityless or if it's equivalent to being uncommitted; i.e. should a clear-cut identityless class still be able to have an identityful subclass, or does that clearly break something.
>>
>> It breaks flattening.  If an identityless class is flattened - and we
>> want to preserve the option to do this for bucket 2 values that are <=
>> 64 bits - then we can't assign a subclass instance to a slot (field /
>> array element) declared to be the superclass's type as we may have to
>> truncate the subclass to have it fit.
>
>
> Right. I guess I was figuring that the mere fact of the idenityless class being non-final would already destroy that?
>
> Supposing this justifies requiring `final` for these classes, then my question evaporates. I wasn't sure though. Even losing flattening entirely doesn't leave you worse off than B1.

The model, up till now, has required `final` on identityless classes,
though this restriction was born out of bucket 3 requirements of
flattening.  Changing it for B2 to allow subclassing will have a lot
of unpleasant knock-on effects:

* Lose flattening (at least for non-final B2 classes)

* Break the construction model:  B2 & B3 classes are instantiated by
an `invokestatic <new>()X;` bytecode sequence rather than the `new;
dup; invokespecial <init>()V;` sequence of B1 classes.  In the B2/B3
sequence, there's no call to super class constructors which means
either not running the super class's `<new>` method or .... maybe,
grimacing, call `super.<new>()X` and do a field-by-field copy of X in
SubX's `<new>` method?  It becomes really ugly really quick.

* Scalarization: I think it would also impede scalarization /
reconstitution of B2 classes as compiled code wouldn't know a priori
the shape of a B2 class.  By giving up identity, it becomes "free" for
the JIT to split a B2/B3 class into individual fields and later
reconstitute the value into a complete aggregate.  Allowing
subclassing of B2 classes would mean that JITTed code would have to
profile the types its seen before scalarizing - turning a freebie into
another potential performance pot hole.  (ie: OSR+recompile for new
types, limits on the profiled types, etc)

And while these can be viewed as implementation concerns, they start
to negate the benefits of having an identityless class in the first
place.

Let me turn the question around: What do we gain by allowing
subclassing of B2 classes?

--Dan