Lazy statics (was: Feedback / query on jextract for Windows 10)

[Brian Goetz]

>> Reframing as caching makes it more obvious that we have to be clear
>> about what guarantees we are offering, especially in the instance
>> case; are we guaranteeing to execute the method no more than once, or
>> is it OK for multiple threads to race to initialize the cached
>> value?  What visibility guarantees do we make?
> So, it seems to me that caching is a bit clearer in setting
> expectations when it comes to migrating away from a "final static"
> field, as well as capturing the throwy nature of these things.
>
> The point you raise about thread racing to init an instance constant is
> a well taken one, and I think it's a pretty bad problem to have to
> solve - of course we have the tools (atomic access, etc.) but seems
> expensive-ish, and the performance model is probably not very
> transparent from the client side.
>

Agreed on both points.  I think it is a slightly less magic user model, 
and gives the runtime a little more breathing room because rather than 
tying to a representation (there's a field called x that when read, 
should have this value) we're talking about what result we want to 
achieve (when this method is called multiple times, the result of a 
previous call is cached and reused).

With respect to racing, moving caching into the runtime means that we 
may need knobs for exactly what cache coherence semantics we want.  But, 
we do have modifiers like `volatile` and `synchronized` which could be 
pressed into service to distinguish between "best efforts, last write 
wins" and "only let one thread run this." (Which may, or may not, send 
the right message.)