RFR: 8266530: HotSpot changes for JEP 306

[John Rose]

On May 5, 2021, at 2:27 PM, Remi Forax <forax at univ-mlv.fr<mailto: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 <dholmes at openjdk.java.net<mailto: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 <joe.darcy at oracle.com<mailto: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.)

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