Content-type: multipart/alternative; Boundary="1__=08BBE432DFE5467D8f9e8a93df938690918c08BBE432DFE5467D" --1__=08BBE432DFE5467D8f9e8a93df938690918c08BBE432DFE5467D Content-type: text/plain; charset=US-ASCII John Levon cc: oprofile-list Sent by: John Subject: Re: potential message to post Levon 05/27/2004 04:32 PM >Doesn't the JVM provide a way to request all the existing mapping data? No, this is not supported. >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? With this approach, oprofiled would be responsible for dynamically processing new JIT events as they are added to the JIT log. >The kernel data buffer does not contain timestamps (and I'm loathe to >introduce them). I do not believe that the race problems with the >dynamic approach I'm suggesting will be particularly significant I agree with that. I didn't think it would be worth the effort to close all the holes, but wanted to mention the problem. --1__=08BBE432DFE5467D8f9e8a93df938690918c08BBE432DFE5467D Content-type: text/html; charset=US-ASCII Content-Disposition: inline



Inactive hide details for John Levon <levon@movementarian.org>John Levon <levon@movementarian.org>




          John Levon <levon@movementarian.org>
          Sent by: John Levon <moz@compsoc.man.ac.uk>

          05/27/2004 04:32 PM



To: Frank Levine/Austin/IBM@IBMUS
cc: oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: potential message to post
>Doesn't the JVM provide a way to request all the existing mapping data?
No, this is not supported.

>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? With this approach,
oprofiled would be responsible for dynamically processing new JIT events as
they are added to the JIT log.

>The kernel data buffer does not contain timestamps (and I'm loathe to
>introduce them). I do not believe that the race problems with the
>dynamic approach I'm suggesting will be particularly significant
I agree with that. I didn't think it would be worth the effort to close all

the holes, but wanted to mention the problem. --1__=08BBE432DFE5467D8f9e8a93df938690918c08BBE432DFE5467D--