Re: JEP 306 - always strictfp semantics

This is a multi-part message in MIME format...

------------=_1620911124-4557-9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I didn't say to use 0xFFFF, but a value larger than that (for instance 0x40=
000).


----- Mail original -----
> De: "Eugene Kuleshov" <[email protected]>
> =C3=80: "Eric BRUNETON" <[email protected]>, "asm" <[email protected]>
> Envoy=C3=A9: Jeudi 13 Mai 2021 14:53:34
> Objet: Re: [asm] JEP 306 - always strictfp semantics
>=20
> Eric, wouldn't using the 0xFFFF value restrict the API for any other
> potential changes in the flag values?
> Or do you think those will not be possible?
>=20
>   regards,
>   Eugene
>=20
>=20
>=20
> On Thu, May 13, 2021 at 8:45 AM <[email protected]> wrote:
> >
> > 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
> > >
> > > On Fri, May 7, 2021 at 8:01 AM <[email protected]> wrote:
> > >
> > > > >  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.
> > >
> > >   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).
> > >
> > >   regards,
> > >   Eugene
> > >
> > >
> > > > > 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
> > >
> > >
> > > --
> > > 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

------------=_1620911124-4557-9
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

------------=_1620911124-4557-9--