Odd interaction between ArrayList$Itr and Escape Analysis
Vitaly Davidovich
vitalyd at gmail.com
Mon Sep 12 19:13:27 UTC 2016
Hi all,
Vladimir I. and I have been looking at a peculiarity in EA as it relates to
eliminating the ArrayList$Itr. What Vladimir found (and I see it as well)
is that ArrayList$Itr::init isn't always inlined due to "unloaded signature
classes", e.g.:
@ 6 java.util.ArrayList::iterator (10 bytes) inline (hot)
@ 6 java.util.ArrayList$Itr::<init> (6
bytes) unloaded signature classes
I tried to dig a bit further into this, and it appears that what's
"unloaded" is ArrayList$1. LogCompilation shows this (which I think is
relevant):
<bc code='183' bci='6'/>
<type id='709' name='void'/>
<klass id='827' name='java/util/ArrayList$1' unloaded='1'/>
<klass id='821' name='java/util/ArrayList$Itr' flags='2'/>
<method id='828' holder='821' name='<init>' return='709'
arguments='820 827' flags='4096' bytes='6' iicount='1853'/>
<call method='828' count='-1' prof_factor='0.602806' inline='1'/>
<inline_fail reason='unloaded signature classes'/>
<direct_call bci='6'/>
<parse_done nodes='100' live='98' memory='35824' stamp='1.114'/>
</parse>
It looks like ArrayList$1 is a synthetic class generated by javac because
ArrayList$Itr constructor is private (despite the class itself being
private). Here's the bytecode (8u51) of ArrayList::iterator:
public java.util.Iterator<E> iterator();
descriptor: ()Ljava/util/Iterator;
flags: ACC_PUBLIC
Code:
stack=4, locals=1, args_size=1
0: new #61 // class
java/util/ArrayList$Itr
3: dup
4: aload_0
5: aconst_null
6: invokespecial #62 // Method
java/util/ArrayList$Itr."<init>":(Ljava/util/ArrayList;Ljava/util/ArrayList$1;)V
9: areturn
LineNumberTable:
line 834: 0
Signature: #185 // ()Ljava/util/Iterator<TE;>;
The only way I can get the Itr allocation removed in my method is by
causing some other method that does the same thing to be JIT compiled prior
to mine.
Does anyone have a good idea of what's actually going on here? Why is that
synthetic ArrayList$1 such a pest here? It's a bit sad that such a little
thing can prevent EA from working in a perfectly good candidate method for
it.
Thoughts?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160912/7d1dab7d/attachment.html>
More information about the hotspot-compiler-dev
mailing list