RFR: 8266530: HotSpot changes for JEP 306 [v3]
David Holmes
dholmes at openjdk.java.net
Fri May 7 10:47:57 UTC 2021
On Fri, 7 May 2021 04:58:22 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.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>
> - Merge branch 'master' into 8266530
> - Respond to review feedback.
> - 8266530: HotSpot changes for JEP 306
Hi Joe,
I don't really understand the proposed changes. If strictfp is implied to always be true that is fine, but if the ACC_STRICT modifier is applied then I don't see how it makes sense to allow it suddenly appear in places where it is not currently allowed. And if ACC_STRICT is to be undefined then I don't see how these changes suffice. ??
David
src/hotspot/share/classfile/classFileParser.cpp line 4801:
> 4799: // check for ACC_FINAL, ACC_NATIVE or ACC_SYNCHRONIZED as
> 4800: // those flags are illegal irrespective of ACC_ABSTRACT being set or not.
> 4801: (is_abstract && (is_private || is_static || (!major_gte_17 && is_strict)))) {
I'm not sure it makes sense to allow ACC_STRICT to suddenly appear where it would otherwise be illegal. ??
test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpIntMethod60.jcod line 24:
> 22: */
> 23:
> 24: // Code below is equivalent to:
If it is equivalent why do we need the jcod file? Presumably there is something here that differs from what the Java source would produce.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3891
More information about the hotspot-runtime-dev
mailing list