Value types, encapsulation, and uninitialized values
brian.goetz at oracle.com
Tue Oct 16 13:06:38 UTC 2018
I wish I could say it was a "choice" at this point; at this point it is
merely an argument that (IMO) sticking the developer with 100% of the
responsibility for avoiding the default value is a bad balance, and will
be a repeated source of sharp edges. But assuming everyone agreed on
that, there is still quite a range of options here, and comparing the
costs are pretty subtle. So its quite possible that what seems most
natural for the programming model might not be where we land, depending
on what the cost tradeoffs are.
For example, some classes (e.g., Optional, LocalDate) can easily find a
single field which is never nonzero for valid values; this reduces the
cost of checking for uninitialized values significantly, at a small cost
to the programmer. (And if all bits are used, they can explicitly add a
byte/boolean to serve this purpose.) But for others, the unused values
are not as cleanly identified (imagine a 16-bit float class, wanting to
steal one of the NaN bit patterns (exponent=1111, significand != 0) to
indicate "uninitialized". That's harder. Harder still would be asking
the JVM to make an upcall to a Java `isNull()` method from the middle of
the acmp_null bytecode...
So, while the negotiation between the user model and the JVM plays out,
suffice it to say that we're aware that having methods invoked on
"uninitialized" values does not feel very "codes like a class", and
we'll do our best to come up with a balanced solution.
On 10/16/2018 3:31 AM, Stephen Colebourne wrote:
> Agreed. The choice seems sound. What I was driving at with "much
> better" is a performance model where nullable values get closer to 80%
> of the benefits than only 50%. Not that it can be distilled to a
> percentage of course...
> I also agree that a nullable value might need one more bit (which
> might align to a lot more), but I want to ensure that those nullable
> values that can arrange things such that their natural all-zero bits
> is not valid (like LocalDate or Money) can avoid that extra bit.
More information about the valhalla-dev