Hi Kris,
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
JDK-8161210
I think everyone would be very happy to get the root issue in HotSpot fixed!
Thanks!
/Claes
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).
Thanks,
Kris
On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad
<claes.redes...@oracle.com <mailto:claes.redes...@oracle.com>> wrote:
Hi,
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
<https://bugs.openjdk.java.net/browse/JDK-8166840>
Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
<http://cr.openjdk.java.net/%7Eredestad/8166840/webrev.01/>
Thanks!
/Claes
[1]
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html
<http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html>
