RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining
claes.redestad at oracle.com
Wed Sep 28 14:52:36 UTC 2016
right, I don't intend to meander away on a micro-optimization spree and
chase down every case where we're hurt by this corner case in the JDK
and elsewhere (I did check that other core collection classes aren't
affected, though ;-)), but to get this simple and possibly high-impact
quick fix out of the way to unblock other work I'm doing, specifically
I think everyone would be very happy to get the root issue in HotSpot fixed!
On 2016-09-28 16:40, Krystal Mok wrote:
> Hi Claes,
> For this particular case, this JDK-side change looks good to me.
> Let me post out the HotSpot version of the change and let you guys
> decide whether or not you guys want to take that version (which will
> take care of the ArrayList$1 case without the JDK-side change).
> On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
> as discussed recently on hotspot-compiler-dev, 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
> 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/
More information about the core-libs-dev