RFR: 8266530: HotSpot changes for JEP 306

[Joe Darcy]

On 5/5/2021 2:27 PM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Joe Darcy" <darcy at openjdk.java.net>
>> À: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
>> Envoyé: Mercredi 5 Mai 2021 23:03:18
>> Objet: RFR: 8266530: HotSpot changes for JEP 306
>> Please review these VM changes in support of JEP 306: Restore Always-Strict
>> Floating-Point Semantics.
>>
> with my ASM hat,
>
>> JEP 306 is considering the following changes to the JVMS:
>>
>> 1) Require "strict" floating-point evaluation in all circumstances.
>> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit
>> position back to undefined for methods. For class file versions, 46 through,
>> ACC_STRICT would remain a defined modifier.
>>
>> Since all floating-point evaluation is done strictly, a modifier bit is not
>> needed to indicate this anymore. There are a few mandated modifier checks when
>> ACC_STRICT is defined, such as not allowing an "abstract strictfp" method.
>> These checks in classFileParser are now conditional on the class file version.
>>
>> The tests verify  "abstract strictfp" triggers a ClassFormatError  for version
>> 60 and does not trigger an error or exception for version 61. (As an undefined
>> bit in version 61, the VM is supposed to ignore it.)
>>
>> FYI, the javac and core libs portions of JEP 306 are out for review under
>> https://github.com/openjdk/jdk/pull/3831.
>>
>> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither
>> relies on the other:
>> * javac will not output class files which expose the difference in class parsing
>> behavior; the ACC_STRICT modifier will not be set in any version 61 class file
>> emitted by javac.
>> *  since HotSpot already does all floating-point evaluation strictly, no changes
>> are needed to support strict evaluation.
> I would prefer the VM to reject ACC_STRICT (if version >= 61) instead of ignoring it.
> Given that we now have a mono-repo, there is no flag day issue.

That is true from a JDK development perspective. However, the general 
JVMS guidance is:

"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. "

We haven't had a bit position go through undefined -> defined -> 
undefined before so there isn't direct precedence on how the situation 
should be treated.


>
> The problem of ignoring it is that classfile producer other than javac will not be updated for v61 since the maintainer of the tool may be not aware of this change so every tools will update at some point some sooner, some later. Given that ASM is based on Visitors from different libraries that can be plugged one with the other, for users of those libraries they may see side effect of one library being updated and another not being updated yet. By example, the  ACC_STRICT on methods will be removed but not the one on classes or vice-versa.

As a reminder, at the VM level strictness only exists as ACC_STRICT on 
methods; there is no type-level strict modifiers in the VM, unlike in 
the Java language.

-Joe