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