Re: JEP 306 - always strictfp semantics

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

------------=_1620910428-4557-8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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?

  regards,
  Eugene



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

------------=_1620910428-4557-8
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

------------=_1620910428-4557-8--