Recall from the last chapter that wait
and notify
always inflates thin locks to fat locks in JRockit. Locks that are frequently taken and released, but are only held for a short time might do better as thin locks. So, immediately using wait
or notify
on a new object will create a new monitor and consequently a fat lock that might lead to performance overhead.
Another common problem that causes performance issues is using the wrong heap size for the JVM. Too small heaps trigger frequent and time consuming garbage collections. Too large heaps lead to longer mean GC times and may cause the JVM to run out of native memory. It makes sense to do profiling runs to figure out the memory requirements of your application and try to find an optimal maximum heap size. JRockit Mission Control will almost always provide good data on the memory requirements for a particular application.