JVMS updates as well

[Dan Heidinga]

Some additional comments based on my read through.

4.4.8 The CONSTANT_MethodHandle_info Structure
> Design discussion: the withfield and aconst_init instructions may justify
new forms of CONSTANT_MethodHandle, but for now no changes are made to
reference_kind.

Both instructions need to be incorporated in a method and carry
nest-restrictions.  I don't think we want to reify these instructions as
new MH types.  Better to rely on the programmers intent and have
programmers opt to expose this functionality through methods.

4.4.10 The CONSTANT_Dynamic_info and CONSTANT_InvokeDynamic_info Structures
> We could allow <vnew> here, but the precedent seems to be to avoid any
special method names when using invokedynamic.

Agreed on not allowing special names in invokedynamic.

4.6 Methods
> A method of an abstract class, an identity class, or an interface must
not have the name <vnew>.
and
> If the name of the method is <vnew>, then the descriptor must denote a
return type that is the type of the current class or interface.

We had previously discussed this restriction and I thought we mostly agreed
on dropping it as each previous discussion didn't result in a clear answer
on the value of the restriction.  The intention to allow reflection to use
the return type to treat <vnew> methods as j.l.r.Constructor objects would
violate the invariant that a constructor returns an instance of the
declaring class.  Here we don't have to do that (and can also return null)
so it would weaken the guarantees provided by Constructor and lead to
programmer errors as they aren't used to validating Constructors previous
invariants (which vnew can violate).

I'm also unsure how to read that last clause "... type of the current class
or interface."  I'm interpreting it as "current class or *an* interface" as
<nvew> isn't allowed in interfaces so it can't be "current interface". Is
the intention that the VM loads any class named as the return type in a
<vnew> method descriptor to enforce it is an interface?

Preload
-- need definition of when loading occurs.  This should be added to section
5.3.5 to outline when the Preloaded classes are made available. Because
this is observable behaviour, we should mandate when it occurs.  Or at
least it will occur before stage X.

6.5 Instructions
> aconst_init
> The referenced value class is initialized if it has not already been
initialized (5.5).

I think we have some missing cases around value class initialization that I
think we've talked about previously but I don't see here. Basically, any
Array creation would need to ensure the class is initalized as well as
would static fields of value classes.

Since we're talking about having two classes - the reference class and the
value companion - we should be clear in the spec on how class loading &
initalization for this works.  Given the companion
class is derived from the ValueClass attribute in the reference's
classfile, the spec should indicate that the reference projection is loaded
first, then the value companion.  And that the value companion, not being a
true class, doesn't get its own <clinit>?  Another option here is to hide
this distinction in the translation layer so you can't ask
"Class.forName("Point.val")" and need to instead do a
"Class.forName("Point").valueClass()".

I think we've under-specified this interaction so far and need to add more
text to cover how the two j.l.Class objects relate and how that hooks into
VM-lifecycle events like class loading and initialization.

Also the "ValueClass" attribute proposed in John's "Value type companions,
encapsulated" email from July 3, 2022 seems to be missing from this draft.

--Dan

On Wed, Aug 31, 2022 at 11:49 AM John Rose <john.r.rose at oracle.com> wrote:

> http://cr.openjdk.java.net/~dlsmith/jep8277163/latest
>
> I edited the URL to find the corresponding JVMS updates:
>
>
> http://cr.openjdk.java.net/~dlsmith/jep8277163/jep8277163-20220830/specs/value-objects-jvms.html
>
> I have a few unsystematic comments on the special subject of special
> methods.
>
> In that draft JVMS, we say in 2.9.1
>
> An instance initialization method may not be declared in a value class or
> an interface (4.6).
>
> and in 2.9.4
>
> A value class instance creation method may not be declared in an identity
> class, an abstract class, or an interface (4.6).
>
> Then in 4.6 we reaffirm these restrictions on <init> and <vnew>, along
> with many similar pre-existing restrictions. These are restrictions on
> *declaration* of special methods.
>
> Then in 4.9.1 we have similar static constraints on *uses* of special
> methods, by bytecodes. Such constraints also appear on constants in the
> constant pool, in 4.4.8.
>
> Eventually in 5.3.5 we discover when and what we must throw if any of
> these conditions fail:
>
> If the purported representation is not a ClassFile structure (§4.1, §4.8),
> loading throws an instance of ClassFormatError.
>
> IIRC somewhere there is a place in chapter 4 that tells us that all of the
> many requirements will be enforced. I don’t remember where that promise is
> made. (Remind me?)
>
> The phrases “instance initialization method ” and “value class instance
> creation method” are accompanied by cross references to 2.9.1 and 2.9.4.
> I’m starting to think that the cross references should *also* mention the
> special method names <init> and <vnew>. That would be a new thing for the
> JVMS but makes more are more sense as we add more and more special method
> names. Now we are at three such names; maybe it’s time to mention the names
> along with the cross references. I think I should be able to grep the JVMS
> for <vnew> for mentions of this feature, not just the phrase “value class
> instance creation method” or the section number 2.9.4. For example:
>
> Only the invokestatic instruction is allowed to invoke a value class
> instance creation method (2.9.4 `<vnew>`).
>
> At some time we will want to change JVMS language that says things like
> “not <clinit>, <new>, or <vnew>” to “not a special method name”. Is that
> time now yet? Places that allow some but not all would have to say “not a
> special method name other than <clinit>” or something of that nature. I
> think that would expose some irregularities in our treatment of
> “surprising” names, but that’s all to the good, even if embarrassing.
>
> You have this commentary:
>
> As an alternative naming scheme, we could re-use <init> but give the
> method a non-void return type.
>
> You could also say something like:
>
> An alternative implementation technique could use regular static methods
> (presumably marked with a Synthetic attribute) of a standard name to
> implement constructors of value classes. This would be convenient for some
> tools in that they could treat these factory methods like all other factory
> methods, without learning the new rules for <vnew> symbols, but would be
> inconvenient for other tools, including the JVM, which need to make a clear
> distinction between constructors and other methods.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220907/1ed5b791/attachment-0001.htm>