Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Build Your Own Java Performance Profiling Tool 153

Posted by ScuttleMonkey from the cuppa-diy-goodness dept.
An anonymous reader writes "IBM DeveloperWorks has an interesting look at creating a custom profiler using Java 5 and AOP. From the article: 'Profiling is a technique for measuring where software programs consume resources, including CPU time and memory. This article provides a list of best-of-breed features you might look for in an ideal profiler and explains why aspect-oriented techniques are well suited to achieving some of those features. It also introduces you to the JDK 5.0 agent interface and walks you through the steps of using it to build your own aspect-oriented profiler.'"
This discussion has been archived. No new comments can be posted.

Build Your Own Java Performance Profiling Tool More

Build Your Own Java Performance Profiling Tool

Comments Filter:

  • AspectJ (Score:3, Interesting)

    by El_Muerte_TDS ( 592157 ) on Tuesday March 14, 2006 @04:13PM (#14918656) Homepage
    Byte-code hacking!?
    Why not simply use AspectJ?
    • To say you did it yourself, duh!

      The things he mentions are fun to do, and for some projects they may be necessary, but the big thing seems to be "My profiler is more customized than yours!" As for byte-code hacking and other "Refliective" programming techniques, that's the all-mighty Heavenly Father's (ar at least Matz's) gift to Ruby.

    • Re:AspectJ (Score:5, Interesting)

      by javaxman ( 705658 ) on Tuesday March 14, 2006 @04:46PM (#14918923) Journal
      Byte-code hacking!? Why not simply use AspectJ?

      You could as easily ask "Why use AspectJ", couldn't you?

      I mean... what you're trying to do in the case of profiling is _not_ change the actual byte code you're working on any more than neccessary. Is using the aspectj runtime somehow better than using the -javaagent JVM option? I'm going to guess here... not neccessarilly, unless you're using AspectJ anyway. If you're _not_ using AspectJ and are not familiar with all of the extra syntax that AspectJ introduces, it becomes very unclear that doing your profiling that way is really a good way to go.

      How would you specifically do the same thing they're talking about in the article using AspectJ ? I'm asking as a Java programmer who has shied away from using AspectJ ( the reasons for using it to me have not become terribly compelling; I'm aware that some folks love it ). Is there an article somewhere that spells out how to do the same sort of thing using AspectJ or some other AOP system? Maybe that would be a helpful link, or make another good story.

    • DTRACE and Solaris. Too bad nothing like that exists for Linux and Windows.
    • Correct me if I'm wrong, but doesn't AspectJ also use byte-code hacking?
  • I use the JVMPI by sun which IMHO does a pretty good job and is extremely easy to use. However the custom profiler looks easy enough and will probably be much more accurate. Worth a try for sure.
    • At $JOB-1 I trialled and bought Yourkit's YJP, which is truly excellent, very easy to use and a very effective tool. Moreover, it's not expensive, and the support is pretty good too. I'm just a happy customer, not affiliated in any other way.

  • jrat - Already does everything you need. (Score:5, Informative)

    by tezza ( 539307 ) on Tuesday March 14, 2006 @04:37PM (#14918847)
    Forget this article AOP Build Your Own. By the time you finish reading the article you could have used jrat [sourceforge.net].

    Download jrat here [sourceforge.net]

    I've used it many times, and it's helped me find horrible Hibernate queries, Lucene bottlenecks, Batik rendering pipeline issues. It is fantastic.

    • Sure, JRat is interesting, but I like the DeveloperWorks article's idea of taking the *exact* bytecode you'll be running and instrumenting it. Now if I can just figure out how to shoehorn it into Tomcat ...
      • Now if I can just figure out how to shoehorn it into Tomcat ...

        You can instantiate tomcat yourself, which means you have full control over the loading of the libraries. Just create your own classloader and inject your instructions as they're read from the JAR.

    • The article is more than just how to build an AO profiler -- it's about how to use the Java 5 agent interface to create AO-based solutions. As for jrat -- the big different between JIP (which is discussed in the article) and JRat is that JIP instruments your code at runtime rather than requiring a separate step.
  • I've worked on quite a few contracts where I was part of a massive 3 ring circus to collect Java metrics, so we could make pie charts for PHBs to show their PHBs. Of course the coders with half a brain already knew where their bottlenecks were. Glad to see all my efforts are being taken so seriously.

    • These two tools aren't profilers, there anaylsis tools. hpjmeter uses the output generated by hprof (the profiler that ships with the JDK) and the other tool you mentioned analyzes the garbage collection log. The problem with traditional tools like hprof is that 1: they require native components and 2: they don't let you turn the profiler on and off at runtime and 3: they profile everything -- even things that you as a developer can't change.

  • Er, Why is this in IT? (Score:3, Interesting)

    by W. Justice Black ( 11445 ) on Tuesday March 14, 2006 @04:51PM (#14918970) Homepage
    Seriously. Modifying a program to profile it?

    I'd do that, but I'm a hybrid java developer/IT d00d. Most IT folk I know wouldn't touch a profiler with a 10-foot pole, much less write one and semi-build it into an app. This is a programming topic, not an IT one.
    • Yea, most corporate slug programmers dont even know how to run a profiler, let alone actually understand the output. Thats why you hire fools like me at 200$/hr or more to run profilers and find your damn bugs for you!

  • you really need more than hprof ? (Score:3, Interesting)

    by javaxman ( 705658 ) on Tuesday March 14, 2006 @04:53PM (#14918989) Journal
    I know I'm setting myself up, but... do you really have profiling needs that aren't met by hprof ?

    Using hprof and decent unit testing, you can work out where your problems are, I've found. All of this bytecode hacking and AOP stuff might show how l33t you are, but I'm not convinced it's really *needed*. Just my humble, uninformed opinion, of course, I'm very willing to hear from others. It could be that I'm just not working on sufficiently complex systems, or that I'm spending more time writing unit tests and pouring through hprof results than most folks.

    • I've tried to use hprof on complex systems, and it just isn't up to the task. Try throwing a system that has a few hundred threads, a couple of databases, and a servlet container at it. hprof quickly loses track of what's going on and stops recording long before my first servlet gets control.
      • I've tried to use hprof on complex systems, and it just isn't up to the task. Try throwing a system that has a few hundred threads, a couple of databases, and a servlet container at it. hprof quickly loses track of what's going on and stops recording long before my first servlet gets control.

        Thanks, that was exactly the sort of post I was looking for.

        So, to continue the discussion... do you think the approach outlined in the article would be usable or appropriate for the system you just described ? How

        • I have no idea why hprof gives up the ghost, and lacking source code I never investigated it. As to AOP, I think it's a bad idea. I don't want to recompile my code to profile it, I want to profile the code I've compiled. Not often, and not on a predictable basis.

          That's why I like the bytecode-injection-at-load-time idea - it works with normal code. If I think the code is too slow under the profiler, I can run the same class files without the profiler and see if it's the application or the profiler that'
          • And in AOP, you'll never know that it happens from reading the source code.

            You and I are so on the same page, it makes me smile a little. I officially apologize for pushing the hprof debate just to get this comment out of you, by the way. I think the injection technique looks pretty cool, as I'd much rather do that than modify ( and then have to change, by hand, again ) the source code to place timing information.

            On the other hand, I'm a huge fan of writing unit and 'prototype' tests, although I understa

    • Re:you really need more than hprof ? (Score:5, Informative)

      by andrewwilcox ( 961166 ) on Tuesday March 14, 2006 @05:06PM (#14919095)
      As was noted in the article, hprof has a number of short falls:
      • It is slow. If you've spent any amount of time using hprof, then you know what I'm talking about!
      • You can't start and stop it at runtime. If you've ever tried to profile a web application with hprof, you know what I'm talking about!
      • Filtering. hprof profiles everything and so it's slow and that output is expansive. When I'm profiling code, I want to know how my code is performing, not how some third party library is performing.

      I like hprof -- it's helped me out more times that I can say, but it also has some short comings, which is why I developed JIP

      • This perl script [perlmonks.org]. (Or google for "wherehot.pl")

        It's a relatively simple script I wrote a while back to filter hprof textual output. It tells you things like "which of the code inside com.foo.* is being slow"? And "which of the code inside com.foo.* is causing StringBufffer.expandCapacity to be invoked, and thereby being slow?".

        A further enhancement of it (that I haven't posted yet, sorry) changes the output format to look something like a java stack trace, which means you can take the output of that scri
      • [hprof] is slow. If you've spent any amount of time using hprof, then you know what I'm talking about!

        That's true for the timing mode. The sampling mode is zippy. For most stuff that I do, it's good enough. It's generally pretty obvious which are blocking calls and which are actually using the CPU. Monitor contention can be a bit confusing sometimes, though - a relatively simple operation will have many, many samples because it's waiting on a monitor held by something more complex. This is good to show yo

      • You can't start and stop it at runtime. If you've ever tried to profile a web application with hprof, you know what I'm talking about!

        This is a common problem with badly designed software. Software should be designed so that all parts can be unittested - and hence profiled - independently. Not only will such a design facilitate better and easier testing, it also makes the code more readable, extendable, and reusable.

  • I'm looking for an application that will monitor a specified application and log how long the application is "not responding".

    We use CAD (Computer Aided Design) software, and I would like to justify new hardware by being able to say how much less time we would have to spend waiting on the software if we had faster computers.

    If I had a way to measure how often the cursor was an hourglass in our CAD software during the course of a standard workweek and then benchmark this on a new computer I could have a metr
    • You need a real unix like solaris for this feature and not linux.

      Although I heard linux has limited support for profiling these days I dont know how good it is for monitoring regular applications in userspace.

      • Sorry, we are on Windows. They don't even write a *nix version of this software. Anyone know of a not-responding process monitoring app for Windows? Steve
        • Let me guess"? Autocad?

          Its a shame the cad market is going to windows from unix. Its certainly no unix and the vendors drank the NT coolaid from all teh hype in the 90's.

          • No, it is CoCreate OneSpace Designer.

            >Its a shame the cad market is going to windows from unix.

            I think you meant "from unix to windows"?

            I'm not surprised. CAD is becoming more and more a commodity - it is currently running about $5000 a seat for stuff like SolidWorks or Pro/Engineer. There are less and less dollars to spend on things like multi-platform support.

            Windows is the predominate desktop environment.

            Personally, I don't care what the platform is.

            Steve
            • Okay, this is off-topic, but what the heck. This comment made me curious...


              >Its a shame the cad market is going to windows from unix.

              I think you meant "from unix to windows"?



              I must be missing something. Is "to A from B" somehow different than "from B to A" ???

              • >I must be missing something. Is "to A from B" somehow different than "from B to A" ???

                I'm not sure what you mean. The fellow was (I think) trying to lament how the CAD market was going from unix to Windows (though he /said/ "windows to unix" - I think he meant "unix to windows" since I was saying our software was only available on Windows).

                As I said - I don't care what platform the software runs on.

                Steve

  • here's my profiler (Score:4, Funny)

    by cygnus ( 17101 ) on Tuesday March 14, 2006 @05:36PM (#14919332) Homepage
    public class HomegrownProfiler {
    public static void main(String[] args) {
    while (true) {
    System.out.println("Some people say this'll never be quite as fast as hand-tuned C.");
    }
    }
    }
    • % Some people say this'll never be quite as fast as hand-tuned C.
      % Some people say this'll never be quite as fast as hand-tuned C.
      *snip*

      Well, I think it really depends on whether you downloaded the hand-tuned C as a pre-build binary or compiled it yourself...

  • best-of-breed (Score:4, Funny)

    by teneighty ( 671401 ) on Tuesday March 14, 2006 @06:48PM (#14919992)
    Never use the word "best-of-breed" again. Or else.

  • One reason to do your own instrumentation (Score:3, Interesting)

    by joe_n_bloe ( 244407 ) on Tuesday March 14, 2006 @09:58PM (#14921193) Homepage
    We have a product that requires that profiling be done on a per-object basis. I'm not using the Java class transformer interface, but I am rewriting classfiles in a manner similar to hprof's bytecode instrumentation option (as opposed to the stack sampling option), using JVMTI.

    JVMTI + JNI is pretty slick stuff. The source code to hprof comes with the JDK 1.5 release and is very informative, if overwhelming at first. If I instrument methods very selectively, the effect on runtime speed is minimal.

    OTOH, trying to implement something like this for Perl (my favorite language) would be an exploration of pain the likes of which hasn't been experienced since people were broken on the wheel.
  • I prefer Mercury's profiler. Its for J2EE or .NET applications but it integrates with Load Runner and Business Availabillity Center. There is a free trail here [mercury.com].
  • Look, nobody is using notepad/vi and javac these days to develop anything. And most of the Java software we develop these days doesn't simply run from the command line. Be it a J2EE application or an Eclipse RCP application, most *free* (as in speech or beer) tools don't do the greatest job when dealing with a predefined configuration, such as the aforementioned.

    Please, someone prove me wrong on this, but I can't seem to find a decent code profiler for use with J2EE or Eclipse RCP applications. You can't
  • I've written my own java profiler/coverage tool using JVMTI, JNI which publishes results on a dynamic webpage (see Patty @ SourceForge ). One of the problems when maintaining statistics on execution and line number coverage if you keep it in the same JVM is that it has a large performance impact to continuously look up the buckets (like many profilers do), the buckets where the statistics are kept. So one of the things is to bring down this impact by only profiling certain classes, plus sending all the pro

Slashdot Top Deals

Kleeneness is next to Godelness.

Close