From: John L. <le...@mo...> - 2004-05-26 00:24:49
|
On Tue, May 25, 2004 at 04:20:06PM -0500, Jimmy DeWitt wrote: > Your quoting seems screwed up, or I missed some email. Please be careful to format your emails properly, trying to decode this one gave me a headache. I've attempted to untangle it a bit below, excuse any mis-attributions. > yes, jprof could interact with oprofiled through an API. However, The > daemon may not be "running" when traced java applications are started. > A typical scenario is to "warm-up" an application for hours/days and > then profile for a small trace period. Several profile collections > could me made without stopping the jvm(s). I don't see this as a serious problem. When starting OProfile we can start the stuff that interacts with JVMPI (maybe it could be the same process as oprofiled even, depending on how clean that is). > There is also the issue of multiple JVMs needing to connect to the > daemon. Multiple users may be running JVMs. And the asynchronous > connection/disconnection of the daemon as it is brought up or shut down > would make the daemon more complex. It would, but I think this is a sensible cost to pay. > Either way there is some processing that must be done. The approach > suggested by John Levon puts more work in daemon. Right. But it has the benefit of fitting relatively well into the general OProfile scheme. In terms of long-term maintenance, this is pretty much a necessity for me. > It it might handle the JMPI_EVENT_COMPILED_MEHTHOD_UNLOAD, but given > the ansynchronous nature that data is read out of the kernel sample > buffers, it might not be that easy to do, because there isn't a time > stamp in the sample buffer data that allow the daemon to determine > whether the sample came before or after a > JMPI_EVENT_COMPILED_MEHTHOD_UNLOAD JMPI_EVENT_COMPILED_MEHTHOD_LOAD > sequence. Yep, it's a concern. Can you provide some data on this please (trace of these events with a typical Java program, with timings?) > Due to the JVM producing the mappings in an odd order (from low address > to high). Thus, the number of translated Java methods (regions), it > could be relatively expensive to do the conversion of EIP to method in > the oprofile daemon because the file will be a lot of small mapping with > the newest one at the end, rather than one large mapping for the text > segment of a normal executable. I doubt this will be a serious performance constraint, and we can use standard techniques to mitigate any cost. > We will need fake files to handle the situation where the jvm's/jprof > are started and oprofiled is not running. I don't know what you're talking about here. If oprofiled is not running then by definition we (that is, oprofile) doesn't have to do anything, because it's not running (sorry for the tautology, but I don't know any other way to put it). > jprof currently logs the jitted method starting addresses, module > length (optionally code) and class/method name into a file by owning > pid. An oprofiled API would be a reasonable way to parse jprof > output. You've lost me. Why would we be parsing any output from jprof? I'm talking about hooking directly into the JVMPI API. > Also, What changes will be needed to oprofile kernel driver to allow the > samples to be passed to the user-space daemon? See Will's patch. regards, john |