RFR: 8266530: HotSpot changes for JEP 306

Remi Forax forax at univ-mlv.fr
Wed May 5 21:27:06 UTC 2021


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

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.

If possible, I would prefer ACC_STRICT to be banned instead of being ignored, for version >= 51.

Rémi

> 
> -------------
> 
> Commit messages:
> - 8266530: HotSpot changes for JEP 306
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3891/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8266530
>  Stats: 416 lines in 6 files changed: 414 ins; 0 del; 2 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3891.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891
> 
> PR: https://git.openjdk.java.net/jdk/pull/3891


More information about the hotspot-runtime-dev mailing list