Proposal 3 changes to daemon and report generator
  1) Anonymous mapping data must be maintained by tgid.

Note: This proposal is only necessary in cases where jitted memory locations are re-used.

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]. This interface needs to
     be agreed upon - the above is just an example.
     The data logger then builds a database, in the /tmp/oprofile directory, named
     anon.tgid. At a minimum the database contains a symbol name and the symbol's
     address range.
     The database, which is "owned" by OProfile, can take the form of an ELF executable,
     a flat file, a memory mapped file, or any other convenient data representation.
     The only requirement is that the post-processing tools understand the contents of the database.
     The SFILE must contain a sequence number for each address, if the sequence number
     (provide by the JIT logger) changes it must add a new sample entry.
  2) Add a sequence number field to the sample entry in the SFILE.  
       If methods are rejitted then a sequence count will be incremented.  When the daemon
      gets an anonymous tick it will get the corresponding sequence number.  
      As an alternative, a different offset/token can be used instead of a sequence number.  
      The sequence number would allow the daemon to know which instance of a symbol the sample
      can be attributed to. A sample at offset 100 may not be executing the same code as a previous
      sample at offset 100 if the code for the method was re-generated at the previous memory location.
      The sequence number would identify which instance of the method was running when the sample
      was taken.

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.
  2) opreport must take into account that the SFILE contains sequence number
     to select the corresponding method information.

JIT data logger
  1) Implemented as a shared library.
  2) Receives tgid and JIT mapping data from the JIT and maintains a database
     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 database is /tmp/oprofile/anon.tgid.
     The database is a format which the post-processing tools understand
     a custom file that contains address to name and sequence information.

  * Closed  JIT mapping files are erased.(at opcontrol --start)
  * JIT makes calls to the "JIT Data Logger" to write mapping data. It is the
    logger's responsibility to maintain the mapping data in whatever form
    it wants. It is also responsible for the jitted sequence.
  * 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
    including sequence number for anonymous samples..
  * User requests a report: opreport --anon-samples -l ...
    - opreport generates list of sample files to include in the profile.
    - When it comes across an anonymous SFILE it invokes something other than bfd
      to do symbol resolution.

  1) Common JIT mapping data format maintained by OProfile.
  2) OProfile does not have to understand the JITs, other than providing
     one interface for the JITs to log their mapping data.
  3) Design should work with any JIT (java, C#) and with multiple, simultaneous JITs.
  4) Works whether the JIT is started before or after the daemon.
  5) Location of JIT mapping data is up to the logger (but must coordinate with daemon)
  6) No "packaging" issues: everything is part of OProfile.
  7) No rejit holes.

  1) Increased overhead for profiled scenario:
     - JIT mapping database must be built as scenario runs, causing interference.
       The magnitude of the impact will depend on the type of database format chosen.
  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 get the current sequence number.
  4) Change(s) to reporting tools.
  5) adding a sequence number to the sample data structure.
  6) Sample files would have duplicate address, different sequence numbers.