Re: JEP 306 - always strictfp semantics

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

------------=_1622734760-12833-21
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Resurrecting that thread.

Just to be sure,
with respect to JEP 306 [1] (ACC_STRICT semantics always on), which propose=
 that the VM simply ignores ACC_STRICT,
do we agree to mostly do nothing and let users of ASM decide if they want t=
o generate V_17 bytecode with or without ACC_STRICT ?

In that case, the only change is that the combination ACC_ABSTRACT + ACC_ST=
RICT is now valid with V_17 while it was not previously valid so the CheckC=
lassVisitor need to be slightly changed.

regards,
R=C3=A9mi

[1] https://openjdk.java.net/jeps/306

----- Mail original -----
> De: "Eric Bruneton" <[email protected]>
> =C3=80: "Eugene Kuleshov" <[email protected]>
> Cc: "asm" <[email protected]>, "Remi Forax" <[email protected]>
> Envoy=C3=A9: Jeudi 13 Mai 2021 14:45:46
> Objet: Re: [asm] JEP 306 - always strictfp semantics

> I like the idea of using a value > 65535 for ACC_STRICT_NEW_SEMANTICS.
>=20
> Eric
>=20
> ----- 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
>>=20
>> 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_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.
>>=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).
>>=20
>>   regards,
>>   Eugene
>>=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_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
>>=20
>>=20
>> --
>> 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

------------=_1622734760-12833-21
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

------------=_1622734760-12833-21--