RFR: 8266530: HotSpot changes for JEP 306

Harold Seigel hseigel at openjdk.java.net
Thu May 6 13:40:52 UTC 2021


On Wed, 5 May 2021 20:57:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics.
> 
> 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.

src/hotspot/share/classfile/classFileParser.cpp line 4802:

> 4800:           // those flags are illegal irrespective of ACC_ABSTRACT being set or not.
> 4801:           (is_abstract &&
> 4802:            (is_private || is_static || (major_gte_17 ? false : is_strict)))) {

Lines 4802 and 4830 would be simpler if changed to:
   (is_private || is_static || (!major_gte_17  && is_strict)))) {

test/hotspot/jtreg/runtime/strictfp/StrictfpModifierChecksTest.java line 56:

> 54:                 throw new RuntimeException("Should not reach; expected ClassFormatError not thrown");
> 55:             } catch (ClassFormatError cfe) {
> 56:                 ; // Expected

Could you add something like the following to ensure that the right ClassFormatError exception is being thrown:

            String eMsg = cfe.getMessage();
            if (!eMsg.contains("has illegal modifier")) {
                throw new RuntimeException("Unexpected exception message: " + eMsg);
            }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3891


More information about the hotspot-runtime-dev mailing list