CONSTANT_Class_info and L-envelopes

Frederic Parain frederic.parain at oracle.com
Fri May 8 14:50:06 UTC 2020


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
>> 
>> 
> 



More information about the valhalla-dev mailing list