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