Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I am going to attempt answering my own question with the help of this <a href="https://gist.github.com/1165804#file_notes.md" rel="nofollow noreferrer">link</a> posted by <a href="https://stackoverflow.com/users/540873/thomas-jungblut">Thomas Jungblut</a>.</p> <pre><code>260 2% performance.api.PerformantIteration::iterateWithConstantSize @ 19 (59 bytes) 268 3% performance.api.PerformantIteration::iterateWithDynamicSize @ 12 (57 bytes) 272 16 performance.api.PerformantIteration::iterateWithConstantSize (59 bytes) 278 17 performance.api.PerformantIteration::iterateWithDynamicSize (57 bytes) </code></pre> <p><strong>First column</strong></p> <p>The first column '260' is the timestamp.</p> <p><strong>Second column</strong></p> <p>The second column is the compilation_id and method_attributes. When a HotSpot compilation is triggered, every compilation unit gets a compilation id. The number in the second column is the compilation id. JIT compilation, and OSR compilation have two different sequences for the compilation id. So 1% and 1 are different compilation units. The % in the first two rows, refer to the fact that this is an OSR compilation. An OSR compilation was triggered because the code was looping over a large loop, and the VM determined that this code is hot. So an OSR compilation was triggered, which would enable the VM to do an On Stack Replacement and move over to the optimized code, once it is ready.</p> <p><strong>Third column</strong></p> <p>The third column <code>performance.api.PerformantIteration::iterateWithConstantSize</code> is the method name.</p> <p><strong>Fourth column</strong></p> <p>The fourth column is again different when OSR compilation happens and when it does not. Let's look at the common parts first. The end of the fourth column (59 bytes), refers to the size of the compilation unit in bytecode (not the size of the compiled code). The @ 19 part in OSR compilation refers to the osr_bci. I am going to quote from the link mentioned above - </p> <blockquote> <p>A "place" in a Java method is defined by its bytecode index (BCI), and the place that triggered an OSR compilation is called the "osr_bci". An OSR-compiled nmethod can only be entered from its osr_bci; there can be multiple OSR-compiled versions of the same method at the same time, as long as their osr_bci differ.</p> </blockquote> <p><strong>Finally, why was the method compiled twice ?</strong> </p> <p>The first one is an OSR compilation, which presumably happened while the loop was running due to the warmup code (in the example), and the second compilation is a JIT compilation, presumably to further optimize the compiled code ?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload