RFR: 8266530: HotSpot changes for JEP 306

[Joe Darcy]

On 5/5/2021 4:57 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "joe darcy" <joe.darcy at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>, "Joe Darcy" <darcy at openjdk.java.net>
>> Cc: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
>> Envoyé: Mercredi 5 Mai 2021 23:51:20
>> Objet: Re: RFR: 8266530: HotSpot changes for JEP 306
>> 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3831__;!!GqivPVa7Brio!MAWcvmVSAYuu0lSA6QkqCKenK94TXTIv8klSIlodHn7whAL3J-R3pnc1U9rFKZqw$ .
>>>>
>>>> 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.
> Given that its value 0x800 is not used on other members, it can be reused to indicate something on class/field/method.
> So we may want to recycle it
>    undefined -> defined -> undefined -> defined


Yes; the intention of undefining it now is to allow the possibility of 
the flag position being assigned to another purpose in the future for 
later class file versions.

-Joe