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