Valhalla EG 20191218

[David Simms]

- Everyone has questions for Brian regarding the new model
  - John:
      - wants to talk about atomic inline types
      - looking forward at GS, a point about the current signature 
processing implementation, note to IBM, how's yours ?
  - Remi:
      - Q to Brian: Why a `public interface` and `private inline` is an 
issue ?
      - Brian: Doesn't want it as an issue, keep it on the list of 
things we might try, rather than place premature restrictions...yeah we 
can get further down the track with the translation story.
  - DanH: how will this interface be generated, look like initially 
`javac`'s job, but subsequent email suggest alternatives
      - Brian: Yeah, the doc is "stake in the ground", DanS has 
discussed abstract class and John VM lifting and giving "*as-if*" semantics
          - Not religious about it, email discussion between John and 
DanH/Tobi
  -  John: was thinking about tweaking at the resolution level, 
shouldn't be much work there.
      - Worried about the cost of loading all the class metadata twice
      - Doesn't want to double the cost of loading `inline class`
      - Prototype and spec cost is should be low
  - DanS: why does the VM need to know about the reference project
      - John: access control
      - Simms: um migration `invokevirtual`->`invokeinterface` ?
      - John: use auto bridging
      - Brian: we haven't needed to use that hammer yet, maybe we hold off ?
      - DanH: talking to John we might see auto bridging as more 
powerful and help avoid more problems
      - Brian: agree auto-bridging could be great for a lot of things...
      - ...wondering if we can prototype with existing tools first, and 
maybe replace with bridging
      - Discussion of complexity cost (not all of which is understood)
          - Proceed with simplistic prototype, mostly `javac`
          - Parallel work on auto-bridging ?
  - DanS: alternative: simple flag for (abstract) class that extends 
inline (which is special yeah)
      - Have to handle constructors...
  - John: marker interface ?
  - Brian: interesting case is `Number`, (well sub-classes of), still 
issues with all of the above
  - DanS: for the setup of classes relating to inlines, can we just 
ignore the constructors ?
  - Remi: does it have to be `abstract` ?
  - Brian: `new Object()` is the smell, thinks it is easy to migrate 
people off this pattern
  - Remi: should we just not allow "regular users" to easily add inline 
keyword, to many dangers...
  - Brian: tooling is going to want add "make this inline", we need to 
educate

  - John: warming to the idea of abstract classes
      - Give up init calls
  - Brian: side steps invokevirtual etc
      - Simple lift all public to abstract...

  - John: next bid auto bridging for rid us of redundancy
  - Brian: think we have disconnect of "auto bridging" definition 
(as-type method, but no byte-code needed)
  - John: specified BSM for missing bits...
  - Brian: ...oh, that's totally not what I was thinking
      - Bridges required only known at compile-time (not enough info at 
runtime), just want to specify as-type method which the VM would hook up
  - John:
      - So yeah javac totally specifies what is needed, they the magic 
to make it work might

  - John, question to DanH/Tobi; ok with "atomic class declaration", to 
guarantee tearing can't happen
      - DanH: would like to nail down the spec, (volatile memory order etc)
      - John: something similar to handling longs, use 
"`__AlwaysAtomic`" for now
      - DanH: this seems like a necessary feature

Next Valhalla EG meeting, 15th Jan

Have a great holiday break

/Mr. Simms