From: Frank L. <le...@us...> - 2004-05-27 19:52:32
|
Since the generated jit code could have been generated long before the profiling starts, but be used during profiling, it is probably important to ensure that the mechanism for identifying the jitted code allows for persistent data. We choose files with names that included owning PIDs to provide this information for multiple sources (multiple jvm's). If you wish to provide for a mechanism that allows for reuse of generated code areas, then time stamps are probably indicated. Time stamps for the generated code as well as time stamps for anonymous ticks, this can be used to map the tick to a jitted method. If you wish to further close address to name holes, and correlate the time stamps, consider SMPs that allow for out of sync time stamps. Then one would also need to know for which processor the time stamps are applicable . |
From: John L. <le...@mo...> - 2004-05-27 21:33:10
|
On Thu, May 27, 2004 at 02:52:13PM -0500, Frank Levine wrote: > Since the generated jit code could have been generated long before the > profiling starts, but be used during profiling, it is probably important to ensure that the > mechanism for identifying the jitted code allows for persistent data. We choose files > with names that included owning PIDs to provide this information for multiple sources > (multiple jvm's). Doesn't the JVM provide a way to request all the existing mapping data? 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? > If you wish to provide for a mechanism that allows for reuse of generated > code areas, > then time stamps are probably indicated. Time stamps for the generated > code as well > as time stamps for anonymous ticks, this can be used to map the tick to a > jitted method. 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 regards john |