RFR: 8266530: HotSpot changes for JEP 306

[David Holmes]

Hi John,

Thanks for the detailed response on this. Notwithstanding that, I still 
believe the initial approach here should be a normal deprecation style 
process for the VM. Effectively in 17 ACC_STRICT is deprecated: it is 
implicitly applied to all methods but need not be explicitly applied; if 
explicitly applied it has the same rules as have existed to date. Then 
in 17+N ACC_STRICT use is considered an error and is rejected always. 
Then in 17+N+M we can start reusing the bit value for ACC_MUMBLE.

In terms of the JVMS we don't undefine ACC_STRICT at this stage, we just 
update its semantics.

Just my 2c.

Cheers,
David

On 11/05/2021 6:42 am, John Rose wrote:
> 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
>