rajesh bala

All these flags are specific to JVM and not for javac.

Though JVM arguments can be set for javac using "-Joption", mostly this might not be required. Until you figure out this javac is failing, you should be all set.

~Rajesh.B

Hi Nagendra,

Old gen would be cleaned up as a part of Full-GC. So until max-heap is touched, you might observe that the heap growing linearly. Minor-GC will be cleaning up only the young generation.

Objects are allocated in young generation and promoted to old-generation at the time of garbage collection. Its vast topic to discuss about young-gen, old-gen here.

Survivor space is used as a bucket before moving to old-gen.

Looking at the current details, I believe most of your problems should be sorted out with -server option.

~Rajesh.B

Raja Nagendra Kumar wrote:



groovy integration for a long and repeated tasks specially when subant, ant antcall or java with fork being used. I searched entire hard disk and unable to find hs*.log files of today.

BTW, since you have said java with fork option. Are your jvmargs specifically configured for this forking java process?. I mean, is this forked java process running with all the jvmargs we have discussed?. If so please run with -server option as well.

It would be great if you can post that forking process's ant script alone here (I understand there could be confidential things which you can't post here. You can change the names etc and post the content of that forking script alone here.)

~Rajesh.B

Hi Nagendra,

Did you see any JVM crashing due to OOM?. If JVM crashes and the program exits, it should generate the hs_<pid>.log file.

Usually it would be saved in the directory from where you are running. Or else, the program itself would tell you "please refer hs_<pid>.log for more details".

Worst possible case: Do a complete search in your c:\ (hoping you have installed JDK and your program in c:\) for "hs*.log"

Note that this would be created only when the JVM crashes due to OOM.

~Rajesh.B

Raja Nagendra Kumar wrote:
As I understand PermGen only stores Class definitions. What does Code Cache contain. Any good documentation of sun's impl.

Hi Raja,

JVM's JIT optimizes as the program is running. It internally generates lot of code as it optimizes and puts them in cache. This area is called code cache. In some cases where the recursive inlining optimizations are heavy, it might happen that the code getting generated are big and hence you see the code cache getting filled pretty quickly. This is different from the perm space as per my understanding.

~Rajesh.B

Raja Nagendra Kumar wrote:Rajesh, We are using it in client mode, which I suppose is the default mode when we run the ant script.

rajesh bala wrote:Forgot to ask an important question. Are you running the JVM in client mode or in server mode?

client mode is meant for short lived applications like applets (note that client mode does not do many optimizations). It is meant for starting the JVM as fast as possible.

Can you run the JVM in "-server" mode and post the results. To be short, Server mode does a lot of internal optimizations.

When you say OOM stemming from code cache, do you see code cache just getting full in jconsole?

1. Whenever Sun JVM throws an OOM, it would create a log file in the directory. Ex: hs_<pid>.log where pid is the process id of the JVM

Did you see from that log that the OOM was due to code cache?. If not, we might be looking at a totally different problem altogether this time. If possible, post the contents of the JVM log here.

~Rajesh.B

Forgot to ask an important question. Are you running the JVM in client mode or in server mode?

If its code cache issue, can you try tweaking

-XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=48m (this is just the starting value. You can increment or decrement to suit your needs)

So add the above 2.

Note that XX parameters are not compatible across all JVM releases. Sun has the right to revoke the XX parameter anytime they need. Also, XX parameters in sun may not be compatible with JRockit.

So I would suggest to try the above parameters only in Sun JVM. For JRockit JVM, we have to first check if the problem persists. If so, we have to check for the appropriate parameters in JRockit.

~Rajesh.B

Hi Raja,

It seems like in JVM 1.5 it has to be combined with -XX:+CMSClassUnloadingEnabled in order to take effect (with -XX:+CMSPermGenSweepingEnabled)

Can you add both of these and run it?

Reference: http://blogs.sun.com/watt/resource/jvm-options-list.html

~Rajesh.B

I remember "yourkit" profiler giving details about that. I dont think JProfiler can give such info.

1. Use Yourkit profiler (may be trial version).
2. In memory management, they have a bunch of rules (5 or 6 rules) which can be run against the heap. This is more of memory leak detector.
3. One of the rule would be "find duplicate strings". You can give a try by running some of the rules mentioned there.

Its really hard to explain the internal workings of yourkit here. So I just hinted on its functionality and rules.

If you suspect that the constant pool of JVM is getting full and hence the permspace error, you can find out by running that rule.

But before trying that, I would highly suggest to try those JVM parameters in order to reduce the time spent on it.

PS: Reason for asking for JVM version is that, in Sun Permspace is different than heap. In BEA JRockit, permspace is a part of the max heap you set.

I would probably try to increase the size of the permsize.

If its giving an OOM even after increasing the permgen to more than 128M or 196M, you might have to look at it more closely.

If the above doesn't work, you can try to enable the following 3 options.

http://my.opera.com/karmazilla/blog/2007/03/13/good-riddance-permgen-outofmemoryerror

-XX:+UseConcMarkSweepGCTell GC to sweep PermGen space
-XX:+CMSPermGenSweepingEnabledrequest JVM to Allow classes to be unloaded
-XX:+CMSClassUnloadingEnabledBedank

BTW, which JVM are you using (JRockit or Sun?).

~Rajesh.B

There is a basic flaw in the way you are benchmarking.

As per your program, NOT all the threads are started at the same point. That is the reason, you dont experience the context switching problem.

You started the threads and initialized them well in advance. Perfect!!..But the moment you say .start() it starts working. So, you have to introduce some GREEN_LIGHT signal in your run() method, which would proceed only when all the threads are started.

~Rajesh.B

Can you post what is the heap size you used in your server?

Definitely concurrenthashmap came up at top. But looking at the size it occupies, it doesn't seem to be a major issue.

~Rajesh.B

Sorry about the typo..read as

If its Sun cool-threads technology, then it performs very badly with floating-point operations due to their single FP-unit.