Proposal 1 changes to
1) JIT must not re-use memory
when re-jitting code. JIT
developers can add an option
to guarantee no re-use of memory.
2) Anonymous mapping data must
be maintained by tgid in generated ELF files.
Changes to daemon
1) JIT data logger
This function is
invoked by the JIT whenever something is jitted. The JIT provides,
for instance, tgid:pid:VMA:length:name[:other
data]. The data format needs to
be agreed upon -
the above is just an example.
The data logger
then builds an ELF file, in the /tmp/oprofile directory, named
2) Require an "Anonymous
Sample Resolver" which would be invoked before
adding a sample
to the SFILE. The resolver would accept a VMA/tgid pair
and return an offset
into the ELF file maintained by the logger.
3) Ability to remove closed anonymous
Changes to opreport
1) Add option --anon-samples
This option allows
including anonymous samples "bucket" in reports
and does symbol
resolution when required.
Default is to not
include anonymous samples in reports.
JIT data logger
1) Implemented as a shared library.
2) Receives tgid and JIT mapping
data from the JIT and maintains a ELF file
mapping as a symbol. Typically the symbol name will be
some sort of method
or function name (ie. name in the sample data).
A suggested location
for the ELF file is /tmp/oprofile/anon.tgid.
Anonymous sample resolver
1) Receives a tgid and a VMA
from the daemon and returns an offset into the
JIT mapping (ELF
file and some sort of cookie identifying the file.
The data retuned
is saved in the SFILE.
* Closed JIT mapping files
are erased. (at opcontrol --start)
* JIT makes calls to the "JIT
Data Logger" to write mapping data to ELF file.
* Daemon/profiling session can
start before or after the JIT starts.
* As profiling session progresses
the daemon is logging all anonymous
samples for tgid in /var/lib/oprofile/samples/current/.../tmp/oprofile/anon.tgid/SFILE
* User requests a report: opreport
--anon-samples -l ...
* From this point on processing
continues as it does today.
1) OProfile does not have to
understand the JITs, other than providing
one interface for
the JITs to log their mapping data.
2) Design should work with any
JIT (java, C#) and with multiple, simultaneous JITs.
3) Works whether the JIT is started
before or after the daemon.
4) Location of JIT mapping data
is up to the logger (but must coordinate with daemon)
1) Increased overhead for profiled
- JIT mapping ELF
file must be built as scenario runs, adding trace overhead.
2) Requires new "JIT Data
- There are complexity
issues since JITs, if they support it, may want to
data which allows mapping to a source file/line, mapping
bytecode (in java), and whatever other JIT-specific mappings
want to generate.
- You may choose
to limit what mapping data is allowed via the JIT-to-Logger
3) Daemon will have to look up
every single anonymous sample before writing
it to the
SFILE (to convert from a VMA to an offset).
4) Hole for re-using memory during
re-jitting is not closed, but
can be closed if
the JIT does not re-use memory during re-jitting.