Re: JEP 306 - always strictfp semantics
"ebruneton" (via asm Mailing List) <[email protected]> Thu, 13 May 2021 14:45:46 +0200 (CEST)
| Newsgroups | gmane.comp.java.objectweb.asm |
|---|---|
| Message-ID | <863947011.123098803.1620909946161.JavaMail.root@zimbra73-e12.priv.proxad.net> |
This is a multi-part message in MIME format... ------------=_1620909948-4557-7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I like the idea of using a value > 65535 for ACC_STRICT_NEW_SEMANTICS. Eric ----- Mail original ----- > De: "Eugene Kuleshov" <[email protected]> > =C3=80: "Remi Forax" <[email protected]> > Cc: "asm" <[email protected]> > Envoy=C3=A9: Vendredi 7 Mai 2021 14:09:24 > Objet: Re: [asm] JEP 306 - always strictfp semantics >=20 > On Fri, May 7, 2021 at 8:01 AM <[email protected]> wrote: >=20 > > > The bigger problem is how ASM would map the ACC_STRICT bit flag > > > value when it will be reused by VM in the future after v17. > > > Having two constants with the same 0x800 value would be a bad > > > idea > > > and the int type used for the flags parameters might be already > > > at its > > > capacity. > > > > It's a solution that i've not listed, > > when we introduce ACC_STRICT_NEW_SEMANTICS, we use a value > 65535 > > (it's an int so we have a lot of empty space, we only have one bit > > used by ACC_CONSTRUCTOR) so the ClassWriter can make the > > difference between ACC_STRICT and ACC_STRICT_NEW_SEMANTICS and > > then lower ACC_STRICT_NEW_SEMANTICS to the value of ACC_STRICT > > (0x800). > > > > The main issue i see is that ACC_STRICT_NEW_SEMANTICS will not have > > the value 0x800 as the VM spec will say so if a visitor call a > > method from another library that expect ACC_STRICT_NEW_SEMANTICS > > to be 0x800, it will not work. >=20 > Good point. Remapping will be required. > Perhaps that can be mitigated by requiring both bits ACC_STRICT | > ACC_STRICT_NEW_SEMANTICS to be present (enforce in the > CheckClassVisitor). > Maybe the ACC_STRICT_NEW_SEMANTICS constant could have more than > one > bit (though that may break existing code that is using bit > operations). >=20 > regards, > Eugene >=20 >=20 > > > On Fri, May 7, 2021 at 6:20 AM Remi Forax <[email protected]> wrote: > > >> > > >> Hi all, > > >> the JEP 306 [1, 2] will be soon integrated into the jdk 17. > > >> > > >> This JEP proposes > > >> - to add a warning if the strictfp modifier is used in the > > >> language > > >> - to not generate ACC_STRICT in classfiles anymore if source >=3D > > >> jdk 17 > > >> (major_version >=3D 61) > > >> - to retire retire the ACC_STRICT modifier in the VM, so the VM > > >> will ignore that > > >> flag. > > >> > > >> The idea is in the future to reuse the bit corresponding to > > >> ACC_STRICT for > > >> another usage, > > >> so in the future, the semantics of that bit will changed so > > >> visitors will need > > >> to be updated. > > >> > > >> The question is how we reflect that in ASM, > > >> - deprecating ACC_STRICT seems brutal because if version < V_17, > > >> it's a valid > > >> flag. > > >> - do nothing, after all the VM will ignore this flag seems > > >> dangerous because at > > >> some point ACC_STRICT will mean something different. > > >> - throw an exception in CheckClassVisitor if version >=3D V_17 and > > >> ACC_STRICT is > > >> used on method (it can not be used anywhere else), i fear that > > >> it may be not > > >> enough. > > >> - rejecting ACC_STRICT if version >=3D V_17 in the ClassWriter, > > >> this seems too > > >> strong. > > >> - silently strip ACC_STRICT if version >=3D V_17 in the > > >> ClassWriter as javac does, > > >> this seems sneaky. > > >> > > >> so here are the options, what do you thing ? > > >> > > >> R=C3=A9mi > > >> > > >> [1] https://openjdk.java.net/jeps/306 > > >> [2] https://bugs.openjdk.java.net/browse/JDK-8266524 > > >> > > >> -- > > >> You receive this message as a subscriber of the [email protected] > > >> mailing list. > > >> To unsubscribe: mailto:[email protected] > > >> For general help: mailto:[email protected]?subject=3Dhelp > > > > OW2 mailing lists service home page: http://www.ow2.org/wws >=20 >=20 > -- > You receive this message as a subscriber of the [email protected] mailing > list. > To unsubscribe: mailto:[email protected] > For general help: mailto:[email protected]?subject=3Dhelp > OW2 mailing lists service home page: http://www.ow2.org/wws >=20 ------------=_1620909948-4557-7 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws ------------=_1620909948-4557-7--