Valhalla EG minutes Sept 27

Karen Kinnear karen.kinnear at
Tue Oct 3 20:53:37 UTC 2017

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!



More information about the valhalla-spec-observers mailing list