RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining
Stuart Marks
stuart.marks at oracle.com
Sat Oct 1 00:31:37 UTC 2016
On 9/28/16 4:48 AM, Claes Redestad wrote:
> as discussed recently on hotspot-compiler-dev[1], having a private class with no
> default constructor can lead to C2 failing to inline, due to the synthetic
> bridge constructor using a dummy argument of an uninitialized class. This is
> really a problem in C2, as well as something which could ultimately be resolved
> by nestmates...
>
> However, there is an easy workaround in adding an empty package-private
> constructor. In the most recently found case - a microbenchmark stressing
> MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x speedup.
>
> This is me asking nicely to do a quick-fix for this in java.util.ArrayList$Itr now:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html
Hi, adding the package-access constructor seems like a reasonable thing to do.
However, should there be a comment explaining this? It seems like just having a
no-op constructor is something that is liable to be cleaned up by a well-meaning
individual who didn't happen to see this thread. Something like this:
// avoid creation of synthetic class and bridge constructor
Itr() {}
If this really is a problem in C2, should there also be a reference to a Hotspot
bug that represents this problem?
On the other hand, addition of the constructor does remove a class from the
runtime image, so maybe it's worth it to keep around even if the Hotspot bug is
fixed. But having a comment would be good to prevent this code from being
"cleaned up".
s'marks
More information about the core-libs-dev
mailing list