Hi, I wanted to chime in on this.
(Sorry for not replying directly -- just subscribed.)
I have implemented oprofile support for SBCL (www.sbcl.org), a Common
Lisp compiler using the JIT machinery.
There are three cases of interest:
A. The heap image is mmapped at startup, and contains all the compiled
code objects available initially. I (ab)use the opagant to get
oprofiling for these code objects. This required read()ing the heap
instead of mmapping it to lose the file association. Being able to
deal with file-backed mappings would be helpful here, but this is not
crucial -- making a heap image look like an ELF is doable, and not a
horrible contortion: the heap image is a largely static pile of code
and data, so ELF is not a huge mismatch.
B. Compiled code loaded from .fasl files at runtime. These are
*currently* not a problem, since the .fasl code objects are not
mmapped. We want to update the file format to support mmapping code
sooner or later, however, and having opagant deal with file-backed
mapping would be nice to say the least. Making .fasls look like ELFs
is not impossible in strict sense of the word, but seems like a
gigantic kludge, as a fasl is nothing like an ELF object in virtually
any sense: while it contains code that could be mmapped, most of it is
instructions to be interpreted/executed when it is loaded.
C. Code compiled at runtime. Opagent fits the bill nicely --
file-backings are not an issue. It's not JIT in the Java sense of the
word, but the API is a good match.
So: file backed mappings are useful now, and likely to be more
important in the future -- from a Lisp hacker's POV at least.
(A side issue is that we would occasionally like to move code-objects
in memory, and it would be nice if opagent had something like
-- Nikodemus Siivola