Next Meeting Wednesday October 11 9am PT/ noon ET/…
AI: Dan Smith - update of Condy JVMS changes - without BootstrapCallInfo
AI: John - email of what is coming - including constant bits, constantGroup
(and why more than BsCI provides)
AI: All - nestmate JVMS feedback for Dan S
attendees: Remi, John, Bjorn, Dan H, Frederic, Lois, Mr Simms, Karen
I. MVT: reiterate that we are targeting an Early Access Binary release
this allows us to be more responsive for a smaller set of targeted customers
when value types goes into a real release we will go through the JCP
J1 MVT talk was rejected.
noted concern: consolidation repository is slow
MVT implementation: field with value type
Frederic: if you generate a classfile today we always flatten fields which
are value types
optional flattening should be coming soon (ed. note: Tobias pushed Sept 29)
II. Condy:
Goal is to phase this into releases, with phase 1 in 18.3. JVMS will remove the
BootstrapCallInfo
for phase 1, so no support for lazy resolution. Internally we have prototyped
it (and use internally for some edge cases)
Changes that will be visible:
Today package spec: says as if by MethdHandle.invoke if short arg list, or
MethodHandle.invokewithargs otherwise
To support > 251 arguments, java.lang.invoke.MethodHandle.invokewithargs will
pass a trailing arg list and not check size
[ed. note - please correct if the above was inaccurate]
Concerns with lazy resolution (phase 2):
1. Lois - with Jigsaw you can now call add-reads or add-exports which could
change the resolution of static args.
John: that is ok.
Longer term plan is to provide bootstrap methods that use the BsCI to
1) eagerly or lazily resolve any number of static arguments
2) lazily resolve “if present” - i.e. if already successfully resolved, but
do not trigger resolution
3) support symbolic reference APIs (see Constable)
- get to original symbolic reference - even if resolved successfully or
failed resolution
use case: might want to add an asType to a symbolic reference that
might have failed
Remi: dynamic runtimes - often have part loaded, part not yet created
John: original concept of invoke dynamic - if you were to get a
NoSuchMethodError, might some day
be able to dynamically create a bridge using asType (might
require patching methodHandles into vtables)
2. Dan H - no intention that the argindex maps to e.g. a javap classfile index?
John: NO - not with condy. No promise that this is an constant pool index for
instance
Dan H: intend to replace sun.reflect.ConstantPool?
John: hope so
3. Remi - propose that the BsCI with a constant call info could replace the
ConstantGroup requirement
John: will send an email of anticipated use cases
expect need for condy lazy resolution, constant bits, constantGroup
(compressed set of CP entries to get around CP size limits)
III. Class file Version handling
John described a new proposal in progress - should be out for community review
soon
- modeled after TCP port numbers - e.g. ranges for private use
- propose private CFV #s for experimental use - that are never standardized
- simplest: upper half of the 16 bit range
- allows us to work together
- project would register for a major number
- within a project could use capability bits
- e.g. valhalla could get a number and nestmates, MVT could use different
capability bits so you could combine them
DanH: what about an extra attribute?
Remi: capabilities would be sufficient
John: attribute reading is too late in the class file processing
Dan H: how does this relate to JCP experimental? Would still need an
experimental feature if in JVMS appendix
AI: John: check Brian’s earlier email
IV. J1 plans/ new openjdk projects
J1 attendees: Brian, John, Dan H - openJ9 talk and panel
openjdk projects:
Metropolis - java on java initiative - start with Graal + AOT
- if interested in being on initial committers list - let John know
(Remi: yes please, also suggested Jan Rogers at Google who worked on Jikes VM)
Dan H: JVMCI - get VM metadata - seems tied to Graal/hotspot
- please work with us to have it less tied to our implementation
Project Loom - Fibers/continuations - Ron Pressler who did Quasar, works
for Oracle now
Dan H - similar to MLVM coroutines?
John: goal - skip native stack copying
allocate Continuations in heap and not copy onto the stack (most of it)
e.g. Parrot VM keeps most stack frames in heap
Dan H: Smalltalk heapifies stack
Remi: MVT experimenting with parts of value type buffer outside of
stack - should consider common groundwork
John: will start with mechanism used by the deoptimization framework
and expand
also - stack walking API - goal is to reflect the entire stack
including continuations
Project Loom will need a spec expert group
V. Nest mates - JVMS feedback
1. DanH - will the tests be in openjdk?
Yes - they will be in jtreg soon in the nestmates repository - consolidation
upgrade in progress
Karen walked through the document she had sent about Preparation and Selection.
Please send feedback on this document, or even more importantly any Nestmates
JVMS changes
you believe are needed.
editor’s note:
The only JVMS changes identified so far:
1) lazy loading of nest top - e.g. remove from verifier
2) NestHost - naming change from MemberOfNest
— from Karen’s review of the sections related to selection, preparation,
overriding - they all look good, no
changes needed. In fact they are improved - thanks Dan S!
thanks,
Karen
