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