Javaの実行時最適化の詳細

こんどは、実行時最適化をした場合のProfileを見てみよう。

Flat profile of 7.46 secs (458 total ticks): main

  Interpreted + native   Method                        
  1.3%     0  +     6    java.io.FileOutputStream.writeBytes
  0.2%     0  +     1    java.util.jar.Attributes.read
  0.2%     0  +     1    sun.io.CharToByteDoubleByte.convert
  0.2%     0  +     1    sun.nio.cs.StreamEncoder.write
  0.2%     0  +     1    java.util.zip.ZipFile.getInflater
  2.2%     0  +    10    Total interpreted

     Compiled + native   Method                        
 45.6%   207  +     1    sun.io.CharToByteDoubleByte.convert
 14.0%    64  +     0    sun.io.CharToByteMS932.convSingleByte
  4.4%    20  +     0    java.io.PrintWriter.write
  4.4%    19  +     1    sun.nio.cs.StreamEncoder.write
  3.3%    15  +     0    sun.io.CharToByteConverter.convertAny
  2.9%    13  +     0    sun.nio.cs.StreamEncoder.write
  2.2%    10  +     0    java.lang.String.getChars
  1.5%     7  +     0    sun.nio.cs.StreamEncoder$ConverterSE.implWrite
  1.3%     6  +     0    Test.main
  0.4%     2  +     0    java.io.OutputStreamWriter.write
 80.0%   363  +     2    Total compiled

         Stub + native   Method                        
  5.7%     0  +    26    java.io.FileOutputStream.writeBytes
  1.5%     0  +     7    java.lang.Throwable.fillInStackTrace
  7.2%     0  +    33    Total stub

  Thread-local ticks:
  0.4%     2             Blocked (of total)
  0.2%     1             Class loader
 10.1%    46             Unknown: running frame
  0.2%     1             Unknown: thread_state


Global summary of 7.47 seconds:
100.0%   478             Received ticks
  3.1%    15             Received GC ticks
  0.6%     3             Compilation
  0.6%     3             Other VM operations
  0.2%     1             Class loader
  9.8%    47             Unknown code

まず目に付くのは、total ticksが9788→458と、20分の一になっていることだろうか。
ticksの数と実行時間が比例の関係にあるのかどうかは分からないが、今回の例の場合はだいたいそうなっているようである。
前回は処理の70％を占めていた sun.io.CharToByteDoubleByte.convertは、今回45％程度まで減っている。
Compiledの分類に入っているところを見ると、実行時に最適化が行われたということなのだろう。
その他の処理も、ほとんどは最適化の対象になっているようだ。
インタプリタのままの処理の割合は全部あわせても２％程度と、非常に少なくなっている。
この比較から、Javaの実行時最適化は非常に効果的で適切であるように思える。
しかしそれでも、Ｃのそれに比べると遅い。
次回からは、このProfileの内容を元に、その原因を検証してみたい。