FAQ: why no user-defined default instances?

[Dan Smith]

> On Apr 20, 2023, at 10:59 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On 20 Apr 2023, at 9:03, Dan Smith wrote:
> 
>>> On Apr 19, 2023, at 6:47 PM, John Rose <john.r.rose at oracle.com> wrote:
>>> 
>>> That’s a good point about “hidden indirections”, but it is not true that we always eagerly “stamp out” the canned pointer to the default value. In at least one place (getstatic
>>> 
>>> ), at the same time as we dynamically indirect the hidden indirection, we also check for null and substitute the default instance. That would work for arrays as well. In any case, the JVM has the option of stamping out zeroes in all cases. For hidden indirections, the option is to either eagerly stamp out a pointer to the hidden default or stamp out zeroes and map on the fly to the default instance.
>> 
>> Yes, agree. My understanding of the current implementation of (2) is that we eagerly stamp out arrays and lazily check-and-swap fields.
>> 
>> Of course both of these techniques would also work for a class with a custom default instance, which undercuts the argument that the performance of such a feature would be unacceptable.
> 
> Only slightly.  The JVM is free to modify its internal tactics if the “stamping out” becomes a problem.  It is much less free to do so if the user bustles up and dumps a special pattern on the JVM.

If the problem is to find some way to logically fill an array with pointers to a heap object (that's what category (2) has to do), I think the problem is identical—at the other end of that pointer is an object with some fields, and it doesn't much matter whether the fields' values are zeros or not.

But if the problem is to encode a *flattened* nonzero default instance, then I'm following what you're saying: in category (1), you really wants zeros.

So perhaps one argument against custom default instances is that they "lock in" the less-performant category (2) behavior, with no hope of it ever improving; whereas other kinds of category (2) classes (like atomic ones) might someday start being treated as category (1) as hardware and implementation strategies evolve.