MVT JVMS comments

[Karen Kinnear]

Dan,

Super job on the JVMS draft - and many thanks for having this so early in a cycle.

Couple of questions/comments:
0) Can you give the terminology summary here please?


1) 4.1. super_class (and 5.3 Creation and Loading): open issue
  We need to discuss the super_class of an ACC_VALUE class.
  It is not java/lang/Object.

  hotspot implementation today uses marker java/lang/__Value.
  Expect to evolve to java/lang/UObject perhaps so it can be shared across the value type and box?
  Perhaps the general answer is the value type root.

  You mentioned at one time that we need to determine what Class.getSuperclass returns for a derived value type -
agreed.

In general, for reflection, Class.forName returns ClassNotFoundException if we try to find a derived value type,
other reflect requests today for EA throw UnsupportedOperationException. You need to use ValueType APIs,
or work on the box for EA.

2) 4.7/4.7.25 new attribute/annotation
Discussion proposed using a RuntimeVisibleAnnotation called ValueCapableClass.
Hotspot implementation today already uses a RuntimeVisibleAnnotation.

current name is jdk.vm.internal.DeriveValueType
Can we keep that or need to change?

Assume that the version support will be >= 54.0

3) 4.9.2 Structural Constraints
If the method returns a direct value class type, only a vreturn instruction may be used, and the type of the returned value must be the same as the type given by the return descriptor of the method (4.10.1.2 <http://cr.openjdk.java.net/~dlsmith/values.html#values-4.10.1.2>).
Should this also mention java/lang/__Value?
Or more generally the common super type of direct value class types?

Where else is it legal to use java/lang/__Value?
We can not use it for field declarations or for array component types.

Do we need it for method parameters other than return values?

4) 4.10.1.1
By loadedSuperclasses - do you actually mean loadedSupertypes?

5) 4.10.1.2: fix “initializing” -> “initiating”

6) 4.10.1.2 The current verifier does explicitly check that an array can only be assigned to Cloneable
and Serializable (I need to double-check with Harold exactly when), so so it looks like you are changing
the rules for array support of interfaces. (Yes, in the more general case interfaces are treated as
java.lang.Object - but this is actually called out).

7) 4.10.1.8  I need to check with Harold on the protected member checking.

thanks,
Karen




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170719/504c4cc6/attachment.html>