Valhalla EG meeting notes March 28, 2018

[Karen Kinnear]

attendees: Frederic, Tobi, Karen, Remi (corrections welcome)

AIs:
Karen: updated https://bugs.openjdk.java.net/browse/JDK-8171335 with requests from meeting (done)
Remi: https://bugs.openjdk.java.net/browse/JDK-8171335 - please add “privileged” annotations you
would like in the new MH.Lookup.defineClass API and why you need them
Remi: https://bugs.openjdk.java.net/browse/JDK-8158765 - “isolated methods” - please add details
of what parts of a current class container you need and what parts you do not. 

I. l-world value types

JVMS update: 4c: http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4c.pdf
Added class file format related changes

2. Nullability concerns:

Goal: future vision - value types as non-nullable and flattenable

Challenges:
1. Migration of value-based-classes
2. backward compatibility - for APIs and bytecodes that take Object, Interface, [Object, [Interface
3. generics
   - want them to work with value types
   - want benefits of flattening
   - how does that work with erasure to Object
   - how does that work with current APIs e.g. Collections: assume [Object
4. longer-term: primitive handling

To handle migration of value-based-classes:
proposing that the JVM be lenient:
   allowing passing nulls for value type arguments
   allowing nulls for local variables and the operand stack
   only catching nulls for putfield and aastore

In classfile: field will be declared as ACC_FLATTENABLE (which implies non-nullable) or not

Proposing javac changes for leniency for value-based-class migration:
   - mark value-based-class as migrating with an annotation: java.lang.ValueBased (for prototyping)
      - javac still considers identity based violations as errors
      - javac allows nullability violations to be warnings rather than errors
      - default @ValueBased is not flattened, container author must opt-in

Note: At this time non @ValueBased classes are by default assumed always flattenable by javac
arrays of any value types, including ValueBased classes are considered flattenable by javac

Still trying to figure out how to handle backward compatibility and generics and primitives in the future

Specific issues with arrays and sub typing:
    [Object and [Interface accept null
    subtypes of [ValueType do not accept null - runtime throws NPE
    how does this work with generics and erasure?
    we do not want any array type conversion under the covers

option 1: what if [ValueType is NOT a subtype of [Interface and [Object (ValueType is a subtype of the Interface)?
    identity assumptions still work, arrays are still identitiful
    would we want javac to explicitly insert conversions to e.g. [Object ?
    trade-off: with [ValueType subtype of [Object, generics just work — except for storing nulls …
    no interest in conversions to Objects and Interfaces -> that leads to accidental temporary identity

Tobi: what if we do not allow migration of value-based-classes to value types?
   Or only for JDK value-based-classes and others get ICCE?

Frederic: Still need to solve the backward compatibility and generics issues

Remi joined …
Remi: how tell the difference with a migrating value-based-class?
Frederic: annotation



II. Nestmates
1. Related to migration of Unsafe_defineAnonymousClass to Lookup.defineClass extensions:
Remi: highlighted an assumption of Unsafe_defineAnonymousClass:
  These classes today are “privileged” in the sense that they are allowed to use privileged annotations (e.g. @stable, @hidden, etc.)
   These are used for lambda proxies - and by lots of other folks

Discussed with John at Belgium Devoxx

expecting that Lookup.defineClass will allow this behavior as well
      - e.g. @hidden - not seen in stack trace
      - e.g. @forceinline - like performance
      - e.g. @stable

Remi: My notes are not clear on @stable - “final is final” - and the limitations of enforcing this
      - Can you please add a detailed request to https://bugs.openjdk.java.net/browse/JDK-8171335 ?

Challenges with “final” fields that are not really final - the VM optimizes based on assuming finality vs.
Serialization has to write the fields

John & Remi are discussing - moving to condy in the language rather than propagating constants that may actually change

2. Dynamic nestmate plans
  MH.Lookup.defineClass
  Karen proposed that you need the Lookup for the nesthost (rather than any random nest member) to be allowed to
dynamically add a nestmate (also added to comment in JDK-8171335)

  Other than that is the proposal ok as is?

3. Remi: concern with dynamic nestmates and Reflection
Reflection today only returns the static members. Will it also return the dynamic members when they are added?
No reflection APIs today distinguish between static and dynamic

4. Who can get to the proposed user data? Anyone with the Lookup used to create the class? Or just the class containing
the userData?

5. editor added: What happens if your nesthost is a Temporary class? is it kept alive as the nesthost? Or do we disallow temporary
nest hosts? What are the use cases for temporary?
Karen: Can we require that a nest host can NOT be a temporary class? We have to keep the dynamic nesthost alive as long as any nestmates live since we do not allow reducing access controls dynamically.

6. Remi: concern about unnamed
There is a hidden performance cost with unnamed classes, which is that you can not generate bytecodes to reference them, you have
to use MethodHandles and invokeBasic
What he wants is - unloading for named methods and fast MethodHandles

Karen: constant pool resolution rules guarantee that we always give you the same answer. We can’t do that if you
can unload the class - the user can replace the class - on disk, on the net, etc. so the next request could load a completely
different classfile for the same name.

Remi: wants bytecodes with no promises for getting the same answer, in fact, he wants ability to do type profiling optimization,
e.g. replacing a generic with a more specialized  type
— only chance today is to use condy - once

Really want functions, classless methods

Karen: In earlier discussion for https://bugs.openjdk.java.net/browse/JDK-8158765
I asked the question:

If you were to have an isolated method, which parts of the current class container capabilities would you
want, and which would you be willing to do without?

Initial response from JVMLS was a request for debug information

Remi: only need static methods, debug symbols and good stack traces

Karen: request - please add details to https://bugs.openjdk.java.net/browse/JDK-8158765
  - easiest if you go through JVMS chapter 4 - and clarify what you actually DO need and do NOT need
  - e.g. no fields (not even static), no class level annotations, …


thanks,
Karen