RFR JDK-8134329: TeeOpTest.java fails across platforms after fix for JDK-8129547

[Maurizio Cimadamore]

Thanks! Pushed.

Maurizio

On 25/08/15 14:56, Sundararajan Athijegannathan wrote:
> Looks good to me.
>
> -Sundar
>
> On 8/25/2015 5:10 PM, Maurizio Cimadamore wrote:
>> Hello,
>>
>> This is a fix for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8134329
>>
>> which has been introduced by the recent fix for JDK-8129547.
>>
>> The problem is that the recent fix changed the hashCode/equals 
>> properties of a BSM key object; such properties used to be identical 
>> to those of the corresponding CONSTANT_InvokeDynamic_info entry, 
>> where dynamic arguments are also taken into account. The fix changed 
>> that to only consider static arguments for BSM key hashCode/equals 
>> computation.
>>
>> While this is the correct behavior, this led to an issue in 
>> ClassWriter.writePool, as the following code:
>>
>> poolbuf.appendByte(CONSTANT_InvokeDynamic);
>> poolbuf.appendChar(bootstrapMethods.size() - 1);
>> poolbuf.appendChar(pool.put(nameType(dynSym)));
>>
>> Makes the implicit assumption that, whenever a new 
>> CONSTANT_InvokeDynamic_info entry is being added, a new BSM entry 
>> will also be added (so that the index of the indy entry is set to 
>> point to the last element of the BSM array).
>>
>> Now that hashCode/equals for BSM keys is different than that of the 
>> corresponding CONSTANT_InvokeDynamic_info entry, there could be cases 
>> in which a new CONSTANT_InvokeDynamic_info is added, but no new BSM 
>> key is created (as an existing key can be reused). This happens for 
>> instance when the invokedynamic associated with the capture of two 
>> method references features same static arguments but different 
>> dynamic arguments (see test).
>>
>> A webrev with the fix is here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8134329/
>>
>> Feedback welcome.
>>
>> Cheers
>> Maurizio
>