| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
| Line: 30 to 30 | ||||||||
| There are many expensive commercial tools for profiling Java programs while they're running, but since Java has the JVMPI interface pretty much anyone can hook into the JVM at run time and find out what's going on. This is another category of programs where there seem to be far too many half-baked efforts, but here are my notes from a few hours of fooling around with various tools. | ||||||||
| Added: | ||||||||
| > > | Mike's Profiler - http://mjp.sourceforge.net/ looks promising, has actual documentation and the maintainer seems to be maintaining it on an ongoing basis. The GUI is easy to understand. Unfortunately it seems to run very slowly and crash before JBoss can fully boot up. NOTE - I need to test 0.06 which has a statistical sampling mode | |||||||
| JTreeProfiler - http://sourceforge.net/projects/jcoverage/ this one streams to an XML file on a per method invocation basis so it's probably unsuitable for anything but trivial profiling (booting JBoss wrote a 2.3GB file). The analysis GUI is interesting and very graphical but hard to make sense of. JPerfAnal - http://sourceforge.net/projects/jperfanal/ can you think of a more unfortunate name for a performance analysis tool? In any case this guy seems to have the right idea in that he reads the stock Sun profiler output so he doesn't need a platform-specific library to gather data. Unfortunately his GUI is lame and there's not one word of documentation. | ||||||||
| Deleted: | ||||||||
| < < | Mike's Profiler - http://mjp.sourceforge.net/ looks promising, has actual documentation and the maintainer seems to be maintaining it on an ongoing basis. The GUI is easy to understand. Unfortunately it seems to run very slowly and crash before JBoss can fully boot up. | |||||||
| JMP - http://www.khelekore.org/jmp/ GTK GUI, written in C. JRat - http://jrat.sourceforge.net/ takes an interesting approach - you "instrument" your code after you build. | ||||||||
| Line: 75 to 75 | ||||||||
Java is very resource-intensive: cpu, memory, and processes. So you might bump into the limits that Unix uses to limit individual user resource consumption. An important one is max user processes which you can see if you run ulimit -a. You probably want to bump this up to 1020 or so: ulimit -u 1020. Other limits that you might bump into are SHMMAX and SHMANY which you can set using files in /proc/sys/kernel/ or by setting values in /etc/sysctl.conf. | ||||||||
| Changed: | ||||||||
| < < | Random Musings | |||||||
| > > | Arrays vs Collections | |||||||
Why don't people use arrays in Java? It seems to me that people get so excited about Collection, Set, List etc that they forget about arrays. Arrays have some definite issues, but they also have some advantages. Arrays are fixed-length so they're not good if you're not sure how many things that you're going to put into them in advance. Their big advantage (which limits their use) is that they're strongly typed. This can be a big advantage in many cases, i.e. where you've got a bunch of the same thing. In this case an array is nice because it enforces type safety in a way that a Collection doesn't. | ||||||||