Valhalla EG 20200115

[David Simms]

- "AlwaysAtomic"
     - John: "bitwise atomic", non-tearability, across the the inline-type
         - No concerns over what is intended, nope
         - In keeping with >= JDK9 JMM
     - Brian: declaration where by you can't accidentally forget use 
site, blanket behavior to be absolutely sure
     - John: "spelling" "bit-wise atomic", so even as keyword
     - Marker interface might be a better way to go as alternative to 
keyword
         - Prototyping might consider annotation
         - Remi: prefers the type
     - Fred: Arrays, we can't declare with modifiers, in the same way
         - Could use Foo.ref[] to guarantee
         - Wrapper auto-boxing...something we could explore...
     - Remi/Brian: "non-tearable" might be better
         - John: but Doug's comment about MM terminology
         - Brian: but MM EGs are not users
         - John: "java.lang.NonTearable" seem like the way to go
- Brian: Dan's proposal on using abstract classes
     - Quick look at current java.base abstract classes, most are 
"well-behavior"
     - Suggestion that the abstract constructor would signal usefulness
     - What if we use ValueBased marker interface on the abstract class
     - Are there too many rules for the user ? This might be hard to explain
         - Banning fields, constructor, synchronized
- John: intention to prototype specialization using constant pool "holes"
     - in particular descriptors
     - Remi: question wildcards ?
     - Brian:
         - we have learned we use erasure as a bound, and don't need 
special wildcard
         - Array co-variant subtyping needed for this to work
- Tobi: question on withfield (and ordering of final fields) do we 
consider that a constructor
     - John: Yes, needs to be added to the JMM note on constructors 
(note on "freeze operation")