Re: JEP 306 - always strictfp semantics

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

------------=_1620389375-6117-14
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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_CO=
NSTRUCTOR) so the ClassWriter can make the difference between ACC_STRICT an=
d ACC_STRICT_NEW_SEMANTICS and then lower ACC_STRICT_NEW_SEMANTICS to the v=
alue of ACC_STRICT (0x800).
>
> The main issue i see is that ACC_STRICT_NEW_SEMANTICS will not have the v=
alue 0x800 as the VM spec will say so if a visitor call a method from anoth=
er library that expect ACC_STRICT_NEW_SEMANTICS to be 0x800, it will not wo=
rk.

  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 i=
gnore 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 w=
ill 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 b=
ecause 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 s=
eems 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 li=
st.
> >> To unsubscribe: mailto:[email protected]
> >> For general help: mailto:[email protected]?subject=3Dhelp
> > > OW2 mailing lists service home page: http://www.ow2.org/wws

------------=_1620389375-6117-14
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

------------=_1620389375-6117-14--