Attendees: Fred, Remi, Simms, John, Brian, Dan S, Dan H, Tobi
- Brian: bring up the string vs trees
- John: we were talking about that in a previous meeting, TLDR: want to
avoid the premature optimizations
- John: don't want to get caught up in naming things that can't be named
- DanH: so to implement the tree, you mean have "live types" in the tree
(or string)
- DanH: agree figuring out from the tree as a starting point just seems
right. Concerns about loader constraints
- John: agreed, security issues surrounding loader constraints are a pain
- Brian: so we did have a tree approach in the previous model 3, which
"worked", sure VM guys would want to tweak anything coming from the
language folks
- See:
[http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html](http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html)
- Brian: meeting next week with small language group, hoping to provide
some documents for a Valhalla VM meeting in April.
- DanH: so a good length of time to preview said docs to key up discussions
- Brian: yeap, will share before April
- Brian:
- so we are going through previous lessons (from model 1-3) in the
light of lworld, and yeah there will be some issues with raw types etc,
nothing surprising
- nesting looks like it is definitely on the table, if this even
mean classes inside of same classfile
- John: working across classloader boundaries
- Brian: classes and methods are specialize-able names
- John: Mapping constant indices, relies on specialization / nest,
suggesting segments
- DanH: so we are putting more things in the class file, localizing
indices to segment/nest might useful
- John: so refresh from last year:
http://cr.openjdk.java.net/~jrose/values/Templates-2019-0325a.pdf
- DanH: looking forward to the April meeting
- Simms: yeah, and it is good there is more than one JVM in the room,
given that implementation details are deep rabbit holes
- Still insist on having a compiler engineer attempt to grok what
JVMS features might break JIT
- DanH: infinite vtable problem come up last yeah, with generic instance
methods ?
- Brian: yeah that is right. But just as we can have class species, we
need method species, with their own specialization (CP), perhaps their
own part of the vtable not part of the class (some handwaving)
- Brian: this is why nesting is a good concept to lean on
