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

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Tue Aug 25 13:56:10 UTC 2015


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



More information about the compiler-dev mailing list