RFR: 8266530: HotSpot changes for JEP 306

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "David Holmes" <david.holmes at oracle.com>
> Cc: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
> Envoyé: Lundi 10 Mai 2021 22:42:35
> Objet: Re: RFR: 8266530: HotSpot changes for JEP 306

> On May 5, 2021, at 2:27 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> If possible, I would prefer ACC_STRICT to be banned instead of being ignored,
>> for version >= 51.

> I sympathize with this, and I had hoped (when Joe set out
> on this work) that the JVMS would cooperate. But it doesn’t,
> in the most straightforward interpretation. (And yes, we
> are making new interpretations here because we are on
> new ground. And it is natural to get here after a quarter
> century; the question is where to aim for the next quarter
> century.)

> On May 7, 2021, at 3:47 AM, David Holmes < [ mailto:dholmes at openjdk.java.net |
> dholmes at openjdk.java.net ] > wrote:

>> I'm not sure it makes sense to allow ACC_STRICT to suddenly appear where it
>> would otherwise be illegal. ??

> This does seem surprising, but it is a clean consequence
> of the stated goal of removing the access modifier from
> the JVM specification. As soon as 0x0800 (ACC_STRICT)
> becomes an undefined flag, non-zero settings become
> legal in all cases. However paradoxical, this follows
> from the JVMS language which Joe quotes. I’d like
> to change that behavior eventually, but that would be
> a separate step.

> On May 5, 2021, at 2:51 PM, Joe Darcy < [ mailto:joe.darcy at oracle.com |
> joe.darcy at oracle.com ] > wrote:

>> "All bits of the access_flags item not assigned in Table 4.6-A are reserved for
>> future use. They should be set to zero in generated class files and should be
>> ignored by Java Virtual Machine implementations.

> The JVMS discourages but does not disallows the setting of
> undefined class file bits. The simplest removal of ACC_STRICT
> will revert it to the status of an undefined bit, which can be
> set to nonzero but… “should be set to zero”. Or else…? There
> is no “or else” specified, therefore we can’t spring a new error
> on the user.

> I think we may need a JEP to define stricter rules for undefined
> modifiers. (And maybe more JEP work for other undefined
> classfile states, though a quick search doesn’t reveal any good
> candidates.) The JEP’s mandated checking can have well-defined
> interactions with configuration flags, such as preview or
> experimental modes, or even a permanent “strict” vs. “lax”
> JVM flag.

> Then we can more confidently extend those undefined or
> ignored `access_flag` bits, to well-defined bits. At that
> point we can recycle the bit position occupied by
> 0x0800 (ACC_STRICT), since we will then be confident
> there will be no undiagnosed noise in that unused channel.

> It might seem reasonable to, at least, anticipate such an
> improvement to the spec, in the one case of ACC_STRICT,
> and require JVMs to throw an error on the vacated bit.

> Indeed, this would be another “interpretation” of the
> intent of theJVM spec, in this new case of removing the
> definition of a modifier bit. But it would add spec
> complexity to the JVM (after strictfp removal) for
> little gain: The special treatment of the vacated bit
> would, indeed, allow it to be recycled sooner, and
> lagging tools would be diagnosed more easily. But
> that’s not enough benefit, IMO, to remove strictfp
> and *then* make its vacated bit position into sacred
> ground that is different from that in other bit positions.

> (A counter argument is that, since we have insisted
> that class file generation tools, to date, be able to emit
> ACC_STRICT in certain circumstances, we should
> help them back away from that behavior by having the
> JVM reject such outputs. But this can be handled by
> a different tool or tool mode, better than having the
> JVM spec centralize such checks.)

All the tools that o know that checks the bytecode are using the JVMS to define their semantics, so if the JVMS is not strict about ACC_STRICT, no existing tools will be, a special tool can be created but will it be used, just for detecting ACC_STRICT, i don't think so. 
So i may be wrong but if the JVMS semantics uses a lax approach about ACC_STRICT, it will have to be stricter at some point in order to reuse 0x800, so in a sense the current position is "we will see later when we will need it", 
which is not a bad position, because perhaps 0x800 will never be reused, or reused but only composed with another bit like ACC_ABSTRACT | ACC_STRICT. 

> So I think on balance it’s best to adjust the JVM spec
> now to appear as if ACC_STRICT had never happened
> (relative to up-rev class files), and consider solving the
> wider problem of undefined modifiers, as a separate line
> of work.

> — John

Rémi