On Apr 26, 2022, at 12:37 PM, Dan Heidinga <heidi...@redhat.com<mailto:heidi...@redhat.com>> wrote:
The question again is what's the primary reason(s) for exposing a B3 (.val) vs B2 instance in APIs? What guidance would we give API designers around the use of B3 .val instances? So one piece of guidance we could give is: "always use value types unless you have a good reason not to." If those semantics are acceptable, we're giving the JVM the best information we have to maximize possible performance gains (both today and in future JVMs). Exactly what JVMs do with the information can be a black box. Alternatively, we can recommend "always use reference types unless you're sure there's a performance need for .val" (which you've nicely expanded into a more detailed set of rules). The nature of those rules depends on the answers to my list of performance questions: - 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? The goal of these questions is to ensure that "there's a performance need for .val" is a corner case. In going down this path, we've opened the box and tied the guidance to properties of current/near-term implementations. So in addition to needing to validate these expectations, we'd want to be confident that the guidance won't look silly in 10 years as implementations change. A risk in either case is that people disagree about how to interpret the guidance, and then you have mismatches between component boundaries, leading to unnecessary problems like expensive heap allocations, noisy null warnings, or incompatible data structures. (Syntactically, I've been assuming that the "good name" would align with this guidance, going to the type we'd recommend using in most cases, but it's definitely possible to discourage general use of the good name, or not provide a "good name" at all.)
