Re: JEP 306 - always strictfp semantics

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

------------=_1620391854-6117-16
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

----- 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:
>=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_CONSTR=
UCTOR)
>> 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 wo=
rk.
>=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).

yes, having ACC_STRICT_NEW_SEMANTICS being encoded as a bit at a location g=
reater than 16 and 0x800 as lower bits is a solution,
the advantage is that there is no need for a remapping because ACC_STRICT_N=
EW_SEMANTICS & 0xFFFF =3D=3D 0x800 and at the same time ACC_STRICT_NEW_SEMA=
NTICS !=3D ACC_STRICT.

We will see when we need to introduce such new flag.

>=20
>  regards,
>  Eugene

R=C3=A9mi

>=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_STRIC=
T 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 AC=
C_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 a=
s 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 l=
ist.
>> >> To unsubscribe: mailto:[email protected]
>> >> For general help: mailto:[email protected]?subject=3Dhelp
> > > > OW2 mailing lists service home page: http://www.ow2.org/wws

------------=_1620391854-6117-16
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

------------=_1620391854-6117-16--