CONSTANT_Class_info and L-envelopes

Remi Forax forax at
Fri May 8 15:19:43 UTC 2020

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.


----- Mail original -----
> De: "Frederic Parain" <frederic.parain at>
> À: "Brian Goetz" <brian.goetz at>
> Cc: "valhalla-dev" <valhalla-dev at>
> 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> 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:
>>> 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

More information about the valhalla-dev mailing list