Re: JEP 306 - always strictfp semantics

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

------------=_1622891924-1065-0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit

If this bit is not yet reused for something else, I think we can do 
nothing as you propose. If/when it is reused with a different semantics, 
I think using an ASM specific bit > 65535 is a good idea.

Le 03/06/2021 à 17:39, [email protected] a écrit :
> 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 to generate V_17 bytecode with or without ACC_STRICT ?
> 
> In that case, the only change is that the combination ACC_ABSTRACT + ACC_STRICT is now valid with V_17 while it was not previously valid so the CheckClassVisitor need to be slightly changed.
> 
> regards,
> Rémi
> 
> [1] https://openjdk.java.net/jeps/306
> 
> ----- Mail original -----
>> De: "Eric Bruneton" <[email protected]>
>> À: "Eugene Kuleshov" <[email protected]>
>> Cc: "asm" <[email protected]>, "Remi Forax" <[email protected]>
>> Envoyé: 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.
>>
>> Eric
>>
>> ----- Mail original -----
>>> De: "Eugene Kuleshov" <[email protected]>
>>> À: "Remi Forax" <[email protected]>
>>> Cc: "asm" <[email protected]>
>>> Envoyé: 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 >=
>>>>>> jdk 17
>>>>>> (major_version >= 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 >= 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 >= V_17 in the ClassWriter,
>>>>>> this seems too
>>>>>> strong.
>>>>>> - silently strip ACC_STRICT if version >= V_17 in the
>>>>>> ClassWriter as javac does,
>>>>>> this seems sneaky.
>>>>>>
>>>>>> so here are the options, what do you thing ?
>>>>>>
>>>>>> Rémi
>>>>>>
>>>>>> [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=help
>>>>>> 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=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws

------------=_1622891924-1065-0
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

------------=_1622891924-1065-0--