Foo / Foo.ref is a backward default; should be Foo.val / Foo

[Dan Smith]

On Apr 25, 2022, at 8:05 AM, Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:

Let’s state the opposing argument up front, because it was our starting point: having to say “Complex.val” for 99% of the utterances of Complex would likely be perceived as “boy those Java guys love their boilerplate” (call this the “lol java” argument for short.)  But, since then, our understanding of how this will all actually work has evolved, so it is appropriate to question whether this argument still holds the weight we thought it did at the outset.

Yeah, I think this has to be the starting place, before we get into whatever other model simplifications, compatible migrations, etc., might be gained.

The expectation for any two-types-for-one-name approach should be, I think, that almost all types referencing the class should use the simple name. The non-default form is for special cases only.

So if we're considering an approach in which the reference type is used almost all the time, we need to establish that doing so will not be considered a "bad practice" for performance reasons. Specifically:

- Are we confident that flattened L types on the stack have negligible costs compared to Q types? (E.g., is there no significant cost to using extra registers to track and check nulls?)

- Are we confident that we can achieve atomic, flattened L types on the heap for common cases?

- Are we confident that the performance cliff required to guarantee atomicity for heap-flattened L types is acceptable in general programming settings?

- Are we also confident that the extra null-tracking overhead of flattened L types on the heap is acceptable in most cases, and only needs to be compressed out by performance-tuning experts?

If the answer to all of those is "yes", *then* I think there's an argument that the model simplifications, etc., could be worth asking performance-crucial code to sprinkle in some '.val' types. But I'm sure we're not ready to say "yes" to all those yet...

A good test for me is this: if we asked everybody to stop saying 'int' all the time, and prefer 'Integer' instead except in performance-critical code, could we effectively convince them to set aside their misgivings about performance and trust the JVM to be reasonably efficient?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220425/b69c31ac/attachment-0001.htm>