User model stacking: current status

[Brian Goetz]

>      - (the controversial one) Atomicity is simply too confusing and
>     potentially astonishing to piggyback on "primitive-ness" or
>     "reference-ness" in a codes-like-a-class world.
>
>
> (Controversial with me at least; I keep thinking who are these people 
> who can understand the rest of how to safely write non-locking 
> concurrent code yet would struggle with this?)

So, the reason I'm being so dogmatic about this is that it undermines 
the belief that "immutable classes are always thread-safe".  I think the 
"objects vs values" distinction is too subtle; hiding atomicity behind 
primitive-ness is too subtle.  I can get behind saying "immutable 
classes are always thread-safe, unless they have been explicitly marked 
as non-atomic", because this is a clear indication that can't be 
confused for anything else.

>
>>     Would I be right that we can achieve primitive unification even
>>     without B4? There is nothing wrong with our delivering many
>>     performance gains while leaving others on the table for later.
>     Yes, delivering primitive unification first means you can't have
>     flat Complex yet.
>
>
> But they still get /often-flat/ Complex? Sounds like 
> /always-flat/ Complex is the perfect thing to punt on then.

They'll get flattening on the stack, but the layout of a Complex[] will 
likely be an array of pointers for a long time, until some heroics kick 
in.  I don't necessarily have a problem with a phased delivery where 
flattening comes later, but I'll note, too, that this is where *most of 
the heap flattening win is* -- arrays of nontrivial numerics.  Because 
there are lots of them, and such code will likely iterate over the 
arrays plenty, doing small amounts of CPU work per element, and then 
stalling when the memory subsystem chokes on a cache miss.  So we can't 
punt for that long.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220509/b8f52dfb/attachment.htm>