Proposal 1 changes to daemon
  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 ELF files.

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
     containing each 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 scenario:
     - JIT mapping ELF file must be built as scenario runs, adding trace overhead.
  2) Requires new "JIT Data Logger" code.
     - There are complexity issues since JITs, if they support it, may want to
       provide mapping data which allows mapping to a source file/line, mapping
       to generated bytecode (in java), and whatever other JIT-specific mappings
       they may 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.