RFR: 8266530: HotSpot changes for JEP 306

[forax at univ-mlv.fr]

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> À: "joe darcy" <joe.darcy at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Joe Darcy" <darcy at openjdk.java.net>, "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
> Envoyé: Vendredi 7 Mai 2021 13:14:03
> Objet: Re: RFR: 8266530: HotSpot changes for JEP 306

> On 6/05/2021 10:14 am, Joe Darcy wrote:
>> On 5/5/2021 4:57 PM, forax at univ-mlv.fr wrote:
>>> Given that its value 0x800 is not used on other members, it can be
>>> reused to indicate something on class/field/method.
>>> So we may want to recycle it
>>>    undefined -> defined -> undefined -> defined
>> 
>> 
>> Yes; the intention of undefining it now is to allow the possibility of
>> the flag position being assigned to another purpose in the future for
>> later class file versions.
> 
> I don't think we can reasonably attempt to do this in the short to
> medium term. The basic proposal is that ACC_STRICT becomes implied from
> this point forward and javac will stop generating it. But the existing
> rules for ACC_STRICT should remain as it is now technically
> "deprecated". Eventually we should reject classfiles >=17 that
> explicitly set ACC_STRICT. Then some time after that we could recycle
> the ACC_STRICT bit value to use for another flag.
> 
> Without a period where we reject the ACC_STRICT bit I think it would be
> dangerous to suddenly interpret its presence as ACC_SOMETHING_NEW.

yes,
given that javac already does not use ACC_STRICT for classfiles version >= 17,
the VM should reject usage of ACC_STRICT now, so ACC_SOMETHING_NEW can be introduced later.

Otherwise we may have ASM visitors that uses ACC_STRICT believing it's the old semantics but in fact it's the new semantics.

> 
> Cheers,
> David
> -----
> 
>> -Joe

Rémi