Browse Prior Art Database

Arcflow of interpreted and jitted methods

IP.com Disclosure Number: IPCOM000013776D
Original Publication Date: 2000-Mar-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 2 page(s) / 29K

Publishing Venue

IBM

Abstract

When analyzing the performance of a java virtual machine, it is nice to have a way to identify where time is spent performing what type of operations and on behalf of what types of processing. In particular, it is helpful to know what time is spent interpreting method(s) and what time is spent executing the jitted method(s). This knowledge may be used to help determine when to jit a method and in determining how much time to spend jitting a method is warranted. Also, summary statistics, such as, the total time spent interpreting and executing jitted methods for a specific run would be helpful in this determination.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Arcflow of interpreted and jitted methods

When analyzing the performance of a java virtual machine, it is nice to have a
way to identify where time is spent performing what type of operations and on
behalf of what types of processing. In particular, it is helpful to know what
time is spent interpreting method(s) and what time is spent executing the
jitted method(s). This knowledge may be used to help determine when to jit a
method and in determining how much time to spend jitting a method is
warranted. Also, summary statistics, such as, the total time spent
interpreting and executing jitted methods for a specific run would be helpful
in this determination.

Please note that it is not sufficient to simply
take the difference between the end time and the
start time to identify the time spent executing an
interpreted method or a jitted method. This is
because other operations could take place, such as,
process switches, timer interrupts, key board
interrupts, etc. Also, other events could occur
during the execution of a method. For example, it
is possible that other operations or threads are
executing code concurrently.

The key to avoiding this problem is in the
processing or analysis phase, which could be either
real time or post processing. We define a
methodology for attributing time spent in a method
or process/thread (pid/tid) by identifying the
current method or process/thread (pid/tid) as a
node and applying base time to the node currently
executing whenever a new event occurs. Nodes are
either a pid/tid node or a child of a pid/tid node.
New child nodes are defined to represent executing
the method interpretively as opposed to executing
the method once it is jitted. This allows the
distinguishing between the execution of the methods
interpretively and the execution of the method once
it is jitted.

This is especially helpful in a mixed mode
environment, where methods may be executed for some
time interpretively as opposed to being jitted
before being executed. Even in a non-mixed mode
environment, some of the initialization methods are
only executed interpretively as opposed to being
jitted before being executed.

Also note that execution of a method may start as
interpreted and end as jitted. In this case there
may be an interpreted method entry hook, a jitted
method entry hook,...