RFR: 8266530: HotSpot changes for JEP 306

[forax at univ-mlv.fr]

----- 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://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.

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

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

Ah, thanks, i've forgotten that.

So the issue will be more with visitors that introduce special methods like constructors or a static block.

Github depressingly found 34,729 snippet of code containing ACC_STRICT (the corresponding ASM flag) [1],
I hope that most of the occurrences are in internal visitors and not in public reuseable ones :(


> 
> -Joe

Rémi

[1] https://github.com/search?l=Java&q=ACC_STRICT&type=Code