On Wed, 2005-05-04 at 19:52 +0100, John Levon wrote:
> What we can do about it
Just that all these things would be very nice for me :-)
(and probably for many developers that would like to do system
wide profiling of a Mono application as well)
As I said, I really cannot take the time to learn how all this
code is working, so I cannot do this work.
I'm just *hoping* somebody will do it...
But as soon as somebody provides a "libagent", I could easily
write a Mono profiling module that is based on it; this is a
thing that is perfectly doable as a "side activity" for me.
My only comment is that the introduction of "agents/java/" would
be a thing "Java" people should do.
If I understand correctly, the code that produces the shared lib
that "extends" the JVM (-runXXX option) would live there.
IMHO, I don't even know if including this code in the oprofile
source tree is really the right thing, and in any case it should
be maintained by people interested in Java, but not necessarily
in the internals of oprofile.
Maybe I am biased by how the Mono code would work...
First of all it would not even compile if you don't have Mono
installed (of course with the relevant headers).
Then, it would be dependent on two interfaces:
- the libagent interface, and
- the internal Mono interface for profiling modules.
Of these two, libagent looks the one that will be more stable
in the long run.
And in any case, the code should be maintained by Mono guys, not
by oprofile guys: in the end it is Mono-specific code that depends
on an oprofile feature (libagent).
You *could* think of it as oprofile-specific code that depends on
Mono, but this would sound strange to me.
If it were for me, I'd just wish that oprofile provided libagent as
a stable interface.
Then, all "agent guys" could base their support of oprofile on
that, in a form that is (of course) agent-specific.
I also think of packaging issues... libagent definitely belongs to
oprofile, but the Mono profiling module should be a separate thing,
so its source code could live in a different place.
And it would be much easier for me if it lived in the Mono svn
repository, where I already have write access ;-)
Now, don't get me wrong: I don't want to force anyone to put or
remove code anywhere.
But for me this is an issue of responsibilities: I feel that the
oprofile people should be responsible for libagent, and libagent
They should not take the burden to write or support code that is
agent specific (where the agent could be Java, Mono, Parrot or
And people working on specific agent support should be able to
update their code without even *asking* the oprofile team on this
list (not that I dislike this list, but again it is an issue of
Finally, there could be agents where there are no "separate"
profiling modules, so that the code using libagent would need to
be embedded in the JIT.
Again, the oprofile developers should not care: libagent should
be the point of contact, and how each agent uses it is an agent
That's it... in any case I just hope somebody will provide this
"libagent" interface ;-)
Of course we can discuss the details (like how debugging info
should be provided), but John's proposal was already perfectly