CONSTANT_Class_info and L-envelopes

[Remi Forax]

----- Mail original -----
> De: "Frederic Parain" <frederic.parain at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Lundi 11 Mai 2020 14:56:04
> Objet: Re: CONSTANT_Class_info and L-envelopes

>> On May 9, 2020, at 21:00, John Rose <john.r.rose at oracle.com> wrote:
>> 
>> On May 8, 2020, at 6:15 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
>>> 
>>> 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.
>> 
>> This problem has existed in class files from day one,
>> since there is no rule of any sort which would exclude
>> duplicate CP entries.
> 
> I’m unpleasantly surprised, but it explains why I was not able to
> find any rule about CP unicity in the spec.
> So far, I’ve never seen a duplicate entry in class file generated
> by javac, which aggressively optimize the constant pool (even going
> to share UTF-8 entries used by Class and String entries).

javac or ASM maintain a hash table of previously seen constants, so there will be no duplicate entries.
some java.lang.instrument agents do quick patch of the class file and append the constants directly at the end of the constant pool without testing if those constants already exist because being just a little faster per class adds up when you have thousands of classes to transform/redefine.  

> 
>> I don’t see why we need to exclude
>> this extra kind of duplication, and the code for checking
>> it will distract us from other things.
>> 
> 
> With the dual notation, we just give users one more chance to shoot
> themselves in the foot. But if the accepted approach to this problem
> is to consider it as a user error, then I can remove the verification
> code.
> 
> Fred

Rémi