Proposal 2 changes to
1) Changes to opreport
- Control whether
or not anonymous samples included in reports.
- Does not need
to know JIT mapping data format.
- Will need to invoke
a data handler(bfd like).
2) Anonymous mapping data must
be maintained by tgid.
3) Anonymous mapping data is
not owned by OProfile. As such, it is the
to delete it when no longer needed. opcontrol --reset
will not remove
any JIT mapping data (anon.tgid files) from the
Changes to opreport
1) Add option --anon-samples
This option allows
including anonymous samples "bucket" in reports.
Default is to not
include anonymous samples in reports.
2) Add option --anon-handler=NAME
This option allows
an anonymous sample handler to "register"
with opreport. The
handler is implemented in libNAME.so and
conforms to a well
defined interface. If the handler can handle
for a particular tgid, opreport calls it
to do all symbol/line
resolution for all anonymous samples
on the tgid.
If the scenario
to be profiled involves more than one type of JIT
this option can
be repeated, providing a different NAME for each
of the anonymous
sample handlers. As an alternative, NAME can be
a comma delimited
list of handler names.
This option implies
1) Handler is responsible for
understanding JIT mapping data format.
2) Implements methods required
by op_bfd() class.
3) Must implement initialization
function which is invoked by opreport
at startup to determine
if this handler can handle anonymous samples
from a given tgid.
- If handler accepts
responsibility for JIT mapping data then
over responsibility for handling all symbol resolution of
samples on the tgid and must be called by opreport for
As an alternative, op_bfd could be sub-classed
to handle this work.
* Stale mapping files owned by
the application are erased.
* JIT writes mapping data to
/tmp/anon.tgid file in whatever format it wants.
* 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/anon.tgid/SFILE
* User requests a report: opreport
--anon-handler=xyz -l ...
- opreport loads libxyz.so
- opreport generates list
of sample files to include in the profile.
- When it comes across
an anonymous SFILE it invokes a predefined function
- If the handler
understands the JIT mapping data in /tmp/anon.tgid
true and opreport associates the handler to the particular SFILE.
functionality should is sent to the handler.
- If the handler
does not understand the JIT mapping data
false and opreport handles anonymous samples as it sees fit.
* From this point on processing
continues as it does today.
1) No additional overhead to
2) OProfile does not have to
understand/communicate with the JITs.
3) Works with any JIT (java,
C#) and with multiple, simultaneous JITs.
4) Works whether the JIT is started
before or after the daemon.
5) Isolates OProfile from needing
to know JIT mapping data format. Each JIT
provider is free
to emit any mapping data it desires and must also
provide a handler
if they want their JIT samples resolved by OProfile.
This does not preclude
OProfile from providing some type of basic support
for common JITs
or common "map" file.
1) Must define a stable bfd-like
interface to opreport.
2) 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.
3) Hardcoded location of JIT
4) Increased opreport complexity.
5) There may be "packaging"
issues (ex. are handlers shipped with OProfile?)