OProfile

Re: OProfile support for generated code From: John Levon <levon@mo...> - 2004-05-27 23:10 On Thu, May 27, 2004 at 05:07:08PM -0500, Frank Levine wrote: > >Doesn't the JVM provide a way to request all the existing mapping data? > No, this is not supported. Bleh... > >If not, couldn't we just write the mapping data to a file, and when > >oprofiled starts, read that in before further mappings are done? > Yes, but then the logic for parsing the persistent data must be coded > anyway. Since this logic must be there, would it be reasonable to > continue using the logic when the dynamic events are issued during > profiling? This can be as simple as reading the file in and then reading from a named pipe or whatever. So, yes, it seems probably reasonable. regards john

Re: OProfile support for generated code From: Frank Levine <levinef@us...> - 2004-05-28 15:15 Attachments: Message as HTML      Instead of a another daemon that handles interaction between the two systems, would it make sense to have a shared object (library) under the control of OProfile that can be loaded by the JVM or whatever agents. This library would have APIs that are used the agents. OProfile would have full control of the underlying mechanism for using the information provided by the agents.

Re: OProfile support for generated code From: John Levon <levon@mo...> - 2004-05-28 15:29 On Fri, May 28, 2004 at 10:01:27AM -0500, Frank Levine wrote: > Instead of a another daemon that handles interaction between the two > systems, > would it make sense to have a shared object (library) under the > control of OProfile that can be loaded by the JVM or whatever agents. > This library would have APIs that are used the agents. OProfile would > have full control of the underlying mechanism for using the information > provided by the agents. That might well be another sensible way of doing it, sure john

609 messages have been excluded from this view by a project administrator.