2009/3/17 Yegor <[email protected]> > > Aren't all profiling tools using the same Java Virtual Machine > Profiling Interface? If so, we only have one CGLIB against one JVMPI, > _not_ one CGLIB against many profiling tools. Profiling tools are > merely front-ends that exchange events with JVMPI. So either CGLIB or > JVMPI (or both) could be responsible for the error. >
modern profilers tend to use the JVMTI hooks that were introduced in Java 5 rather than the experimental, deprecated* JVMPI hooks (* Sun's own words!) http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/ one of these hooks is the ability to redefine bytecode as it's loaded to mix in snippets of profiling bytecode - this appears to be what Profiler4j uses unfortunately while this gives the profiling agent great power it also brings great responsibility ;) because it's not using a standard set of entry / exit hooks added by the JVM, but is transforming bytecode using its own rules. Anyway, I'll have to agree with Stuart. Profiling dynamically > generated byte-code may not give you reliable numbers. It is better to > exclude generated classes from instrumentation target list and instead > measure the performance of classes that call generated code. Note that > I am only talking about CPU profiling. Memory is a different issue. > Have you tried different profiling modes (memory, CPU, code coverage)? > Are all of them failing? > +1 excluding generated bytecode from CPU profiling is a good idea several profiling tools exclude CGLIB classes by default (ByCGLIB$$) but Guice uses its own naming policy for proxies (ByGuice$$) which of course means you need to remember to exclude these types yourself... > Yegor > > On Mar 16, 11:23 am, Endre Stølsvik <[email protected]> wrote: > > Hi! > > > > Thanks for a very informative answer! > > > > > > > > > if CGLIB was generating invalid bytecode then I would expect to see > > > the verify error when you didn't use a profiler - so far I've only seen > > > this when profilers are involved... > > > > Well, the idea was that only when it came "last" to the code, > > transformations it yielded could end up wrong. Thus you would never > > observe an error with this as the sole tool. Also, one of the tools > > could be more robust than the other, so that it consistently handled > > being last, while the other didn't tackle that. Just musings.. > > > > I think that CGLib should fix that "unusualness" of itself (apparently > > the number of explicit pops it sticks in before the multiple return > > points it generates?!), adhering to Postel's law: Be conservative in > > what you do; be liberal in what you accept from others. At least, it > > could have some switch that could produce conservative code (default), > > or drop this for the last bit of performance. And obviously, it might > > well be that it really is the other tools that are in error - but that > > isn't very helpful. > > > > Endre. > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
