CONSTANT_Class_info and L-envelopes

[Remi Forax]

Another solution is to use the preview feature mode instead of a flag,
i.e. only allow L-envelope mode for constant class info if the minor version is all 1s.

Rémi

----- Mail original -----
> De: "Frederic Parain" <frederic.parain at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Vendredi 8 Mai 2020 16:50:06
> Objet: Re: CONSTANT_Class_info and L-envelopes

> The VM flag might be overkill, it’s mostly a remain of the version
> where the policy was enforced globally. I can remove it.
> 
> Fred
> 
> 
>> On May 8, 2020, at 10:44, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> It is sad, but reasonable, that we can't remove this bit of spec tech debt all
>> at once.
>> 
>> I would step back and say: what is the goal of having this flag?  Is it to
>> experiment with tools ability to deal with a mixed world while we try and move
>> towards a unified one?  If so, then your inferred-mode-per-classfile is good;
>> it enforces that file writers do one or the other, while allowing different
>> tools to migrate at their own rates.
>> 
>> 
>> 
>> On 5/8/2020 9:15 AM, Frederic Parain wrote:
>>> Greetings,
>>> 
>>> After the discussions of the past weeks about checkcast and the use of
>>> envelopes in CONSTANT_Class_info entries, a consensus has been reached
>>> for the case of Q-types. However, the case of L-types (should they use
>>> an L-envelope or not) is still subject to discussion. In one hand,
>>> forcing L-type to use envelopes would be a nice unifying move, in the
>>> other hand, it would have a bigger impact on tools, requiring a flag
>>> day approach instead of a smooth transition.
>>> 
>>> The current approach is to continue not to use L-envelopes in
>>> CONSTANT_Class_info entries, but because some people might want to
>>> experiment with L-envelopes, it has been suggested to add a VM flag
>>> to support them.
>>> 
>>> Having a global flag to require that all class files use the same
>>> format (either L-envelopes everywhere or L-envelopes nowhere) seems
>>> impractical because it would require to recompile all classes to
>>> switch from one mode to the other.
>>> 
>>> Being more lenient and supporting both modes causes a new issue:
>>> the double syntax would allow a symbolic reference to a class to
>>> exist in two forms inside a single class file: one form with the
>>> L-envelope, one form without the L-envelope, creating two distinct
>>> constant pool entries. The problem with having two entries representing
>>> a symbolic reference to the same class is that there’s no guarantee
>>> that the resolution of these two entries will produce the same result.
>>> 
>>> One solution to prevent this to happen would be to verify that a given
>>> class is never referenced through two different entries, but this would
>>> add a lot of checks during class file parsing.
>>> 
>>> Another solution would be to have a “mode” per class file, either
>>> always using L-envelopes, or never using them for CONSTANT_Class_info.
>>> The class file doesn’t have to declare which mode it uses, this will
>>> automatically detected by the JVM while processing the first
>>> CONSTANT_Class_info entry, and then enforced for the remaining of the
>>> processing of the class file. A global VM flag controls if the VM
>>> must support the “L-envelope required” mode or reject it (default
>>> is to reject it).
>>> 
>>> This solution has been prototyped here:
>>> 
>>> http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.00/index.html
>>> 
>>> 
>>> It has been tested with manually modified class files, but has no unit
>>> tests provided with the changeset.
>>> 
>>> Before submitting a pull-request, I’d like to have some feedback about this
>>> approach. If you think this approach makes sense, I can push it, otherwise
>>> I’ll drop it.
>>> 
>>> Thank you,
>>> 
>>> Fred
>>> 
>>>