Re: JEP 306 - always strictfp semantics

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

------------=_1620388880-6117-13
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 13:46:27
> Objet: Re: [asm] JEP 306 - always strictfp semantics

> Remi,
>=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_CONS=
TRUCTOR) so the ClassWriter can make the difference between ACC_STRICT and =
ACC_STRICT_NEW_SEMANTICS and then lower ACC_STRICT_NEW_SEMANTICS to the val=
ue of ACC_STRICT (0x800).

The main issue i see is that ACC_STRICT_NEW_SEMANTICS will not have the val=
ue 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
>  As for handling it now, I think the CheckClassVisitor check for V_17
> + ignoring or silently stripping it in the ClassWriter should cover
> it.

ok

>=20
>  regards,
>  Eugene

regards,
R=C3=A9mi

>=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 ign=
ore that
>> flag.
>>
>> The idea is in the future to reuse the bit corresponding to ACC_STRICT f=
or
>> another usage,
>> so in the future, the semantics of that bit will changed so visitors wil=
l 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 bec=
ause at
>> some point ACC_STRICT will mean something different.
>> - throw an exception in CheckClassVisitor if version >=3D V_17 and ACC_S=
TRICT 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 see=
ms too
>> strong.
>> - silently strip ACC_STRICT if version >=3D V_17 in the ClassWriter as j=
avac 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

------------=_1620388880-6117-13
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

------------=_1620388880-6117-13--