Per Halvarsson

+ Follow
since Aug 14, 2008
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Per Halvarsson

Toby Eggitt wrote:On this topic, what profiler tools do people recommend (for use inside Eclipse, specifically)?
I want to look at method timings, object instances, and total memory used by objects of any given class.

The Eclipse Memory Analyzer Tool is a very nice for tool analyzing the heap inside Eclipse.

Othervise you could try JRockit Mission Control. It will also give you statistics about the number of object instances on the heap and how much memory they occupy, both live using the Memory Leak Detector or stored in a file for offline analysis using the JRA-tool. The overhead for method profiling is very low, less than 1% or so, because the tool piggybacks on the hot spot detector the JVM uses. You can get the the Eclipse plugins from the update site. The tool can also give you cheap memory allocation profiling.

Both tools are free to use for development and you can jump to the souce code in your Eclipse projects.
12 years ago
If it is a temporary object the JVM might be able to remove the allocation. For instance this code[1],

can by the JRockit JVM be optimzed into:

mov $0x00000085,%eax

a single machine code mov, that moves 123+10 = 133 = 0x85 into %eax which is the return register.

Modern JVMs usually have a lof different strategies for minimizing the pressure on the memory system; thread local allocation, nurseries, compressed references etc. If you want more detailed information about the allocation pattern in your application you really need to profile it. You could try the profiler that comes with JRockit. It will give you statistics about garbage collection pauses, where in the code most of the allocation occurs, allocation/s and size of the thread local areas. Start up your application like this:

JROCKIT_HOME\bin>java -XXjra:recordingtime=60s,filename=myrecording.jra,latency=true MyApplication

and when the recording has finished open the recording file with JRockit Misison Control. You will probably need at least 100-200 Mb of memory to look at the recording, but not 400-500 Mb as with Netbeans. See this blog for more information:


12 years ago
I took you program* and profiled it using JRockit Mission Control. See the attached picture.

The brown parts are when the JVM is waiting for files to be written to disk, the pink parts are when the JVM is waiting for the memory system to fetch a TLA and the green parts are when the JVM is running. When running with a thread pool size of 4 the CPU utilization goes up to almost 100%(see the graph at the top) and your problem doesn't seem to IO-bound, at least not on my machine. Even though the brown parts look quite large on the picture they are really small if you zoom in on them.

Looking at what methods that were running the most I found that the JVM was copying/allocating objects a lot. The application also spent a fair amount of time in the method IsTerminated() in ThreadPoolExecutor.

* I changed your program so that the amount of data written were 10 times as much. I wanted to get profiling data for at least a couple seconds.
12 years ago
Since you're running WebLogic I would consider switching to JRockit. It doesn't have permgen issues and the JVM has been optimized for WLS.
12 years ago
JConsole uses the attach API and it is only available for JVMs running with JDK 1.5+. If the process is running as a windows service the local attach API might not be able to connect since the process could have been started by another user. The easiest way to fix this is probably to connect using a network port.

=false ...

and add the remote process in JConsole as: localhost:<portNumber>. Or you could use the JRockit JVM and JRockit Mission Control, instead of JConsole. JRMC can discover JVMs on the network if you specify autodiscovery flag at startup.

>java -Xmanegement:ssl=false,authenticate=false,port=<portNumber>,autodiscovery=true ...

and you you'll see the JVM pop up in the browser to the left automatically, right click and choose Start Console. It even works for JDK 1.4, but then you'll have to remove authentication and ssl from the command line.
13 years ago
Have you tried running your application with the JRockit JVM?

It doesn't require a contiguous memory space.

"How to get (almost) 3 GB heap on Windows!

As you may be aware, the maximum heap size on Window using JRockit - or for that matter any JVM we are aware of - has been limited to slightly below 2 GB. There have been two reasons for this. One is that the maximum process size on Windows has been limited to 2 GB, though this can be worked around by using the /3GB kernel switch. The second is that JVMs have required a contiguous memory space for the Java heap for efficiency reasons, which causes the maximum Java heap size to be limited by DLLs loaded into the process address space.

With JRockit 5.0 R26 this barrier is broken! By introducing support for split heaps, we have been able to significantly increase the Java heap size on Windows.

Windows 2003/XP using the /3GB switch (32-bit OS)
1.85 GB - JRockit 5.0 R25.2 (SP2)
2.85 GB - JRockit 5.0 R26 (SP3)"
13 years ago