Valhalla EG minutes 6/21/17

[John Rose]

On Jul 5, 2017, at 12:13 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> Summary of today's discussion, supplemented with some reflection on what I see as the requirements:

Thanks!

> - The specification shouldn't care when the class is derived (though it must occur, naturally, no later than resolution of "Foo$Value"); the specification *might* care when error checking occurs, because that's observable.

Even more specifically:  "when errors are reported".  Checking can happen long before reporting.

> - Current specification draft says error checking occurs when Foo$Value is loaded (5.3), and that "Class or interface creation is triggered by another class or interface D, which references C through its run-time constant pool." So, as a test case: if my program has no references to Foo$Value (direct or reflective), no VCC-related errors would occur.

I would prefer this in MVT, but it's not a showstopper.

In the long term this might be a good move, relative to operations that resolve Q-Foo (not Foo$Value), if Foo is supposed to be "merely an object" until suddenly its value aspect comes into play.  In the usual case where some ACC_VALUE bit is present in the class file, there is no cause to delay error processing.

> - We could redesign this so that the VCC properties are checked during loading/verification of Foo. I am concerned that, where Foo is version 54.0 and has attribute ValueCapableClass, this sort of error checking will violate the Java SE 10 spec.
> 
> Elaborating: we're presenting values as an optional feature of Java SE 10. For a JVM that does not implement the optional feature, JVMS 10 says that a ValueCapableClass attribute on a version 54.0 class file will be ignored. JVMS 4.7.1: "any attribute not defined as part of the class file specification must not affect the semantics of the class file. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize." My interpretation of our mission, in adding an optional feature, is to provide new capabilities while having no impact on existing behavior. We can do new things where JVMS 10 specifies an error; we can't generate new errors where JVMS 10 specifies none.

This is a good point.  It's the right way to manage the spec.

OTOH, it's hard to construct examples where this matters for MVT.  If I forget to use a VM that supports DVTs (or forget to flip the On switch), I am practically certain to get an error if I run my example MVT code.  The error should occur as soon as the DVT is extracted.  But it might also occur if the JVM falls over (due to some bug) when it loads the VCC and asks itself a premature question.  Practically speaking, I will never expect (in MVT) to use a VCC as a POJO with DVTs turned off.

> 
> - We could limit usage/interpretation of "ValueCapableClass" to 54.1 class files. Then eager error checks when loading Foo would be fine. But the ability to work with 54.0 ValueCapableClass class files is an important use case.

Confirmed.  This is why "Shady" speaks of mainly of an annotation to enable VCCs.  (Over-cautiously, it also says "perhaps an attribute".)  I should have mentioned this earlier.

> - Actually, examining that use case more closely, we discussed how attributes are not the right tool at all. We want clients of MVT to be able to generate interesting programs using a vanilla Java SE 10 compiler. The best mechanism to communicate "I'm a value-capable class" using a vanilla Java compiler is annotations, not attributes.
> 
> Tentatively, the spec should be revised so that:
> - The "ValueCapableClass" attribute no longer exists. Delete changes to 4.7 and delete new section 4.7.25.
> - A "value capable class" is a class whose RuntimeVisibleAnnotations includes a ValueCapableClass annotation (package TBD; whether the referenced class must be loaded TBD)
> - As usual, this annotation doesn't impact behavior of class Foo
> - When loading Foo$Value, as specified in 5.3, we'll check that Foo is a value capable class and that it has the right properties

Also:
- The annotation is ignored if the VCC does not have permission to access the annotation.  (It's filtered like @Contended, which is not in the spec.)

This check is complex to implement in general, since it interacts with the bootstrapping of the module system runtime.  But in fact it only needs to work for the specific @ValueCapableClass annotation.  That means a hardwired check to is likely to work, by embedded into the JVM which modules have access to the @VCC annotation.  For @Contended it works because the JVM "just knows" that @Contended lives in an unexported package of java.base.

— John