4

I m using JAVA 5 (32 bit) for my application running on JBoss. But it working fine only for 32bit. As we deploy it on 64bit java5, it throws an Exception

"java.lang.OutOfMemoryError: PermGen space" exception

Is there any Patch required? Is any code code change required?

Thanks in advance.

Navnath
  • 53
  • 2
  • 2
  • 5
  • Did you even check google.com/search?q="java.lang.OutOfMemoryError%3A PermGen space"? There are many hits, including those on SO – Miserable Variable Sep 12 '11 at 05:46
  • @Hermal: it's **not** the same: this one is about PermGen space, while the other one is about heap space. – Joachim Sauer Sep 12 '11 at 06:15
  • possible duplicate of [What can be done with 'PermGen out of space' exception in Tomcat-Spring-Hibernate web application?](http://stackoverflow.com/questions/1124131/what-can-be-done-with-permgen-out-of-space-exception-in-tomcat-spring-hibernate) – Joachim Sauer Sep 12 '11 at 06:16
  • (Note the question I linked to doesn't mention JBoss, but the problem is the same and the answers are better than for other PermGen related questions). – Joachim Sauer Sep 12 '11 at 06:16
  • @Joachim...oops, pretty sure I was pasting the PermGen question. I will change it. – Miserable Variable Sep 12 '11 at 06:17

4 Answers4

7

I have got the same prolem when I run my web application under tomcat or jetty. Permanent genration memory is used for loading the classes and the idea is that "Classes are loaded once and forever". Since I am using quite a lot of libraries and Spring framework, this memory is filled up very quickly espectially when I redeploy the web application several time with out restarting the servlet container.

I found that increasing the maximum permanent generation is not sufficient. You also need to allow the garbage collection to removed the unused classes at runtime, otherwise it will be filled up and throws PermGen space exception. Here are the JVM options that I added for my servlet containers,

-XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

-XX:MaxPermSize is used to set the maximum value of permanent generation. This should be greater than the default size.

-XX:+CMSClassUnloadingEnabled this option is used to allows JVM to unload the class at runtime. By default, class unloading is disable. For Java 5, please read this.

-XX:+UseConcMarkSweepGC, in order for class uploading option to work, this option must also be set (ref)

Also, you should consider upgrading your JVM version. Java 5 is too old.

Community
  • 1
  • 1
gigadot
  • 8,879
  • 7
  • 35
  • 51
3

64-bit Java has twice as long pointers as 32-bit has. Since most of your objects are composed of pointers (references to other objects), you need significantly more memory to run. You run a 64-bit version because your app needs more than 4GB allocated in the first place, don't you? If you don't, you're better off with a 32-bit JVM.

Play with -XX:MaxPermSize= when starting your server.

9000
  • 39,899
  • 9
  • 66
  • 104
  • 2
    64-bit references in Java 5.0 use twice as long references. In Java 6, they use 32-bit references by default (See `-XX:+UseCompressedOops`) – Peter Lawrey Sep 12 '11 at 06:47
2

Is there any Patch required?

Yes, Using the 64-bit Java 6 or 7 which uses 32-bit references by default. Java 5.0 uses 64-bit references. I don't imagine this will be added to Java 5.0 as it hasn't been freely supported for almost two years. (You can pay to support it BTW)

In the Sun/Oracle JVM, objects are 8 byte aligned. The JVM uses this fact to use 32-bit references to address 32 GB of memory. (8 * 4G). With direct and memory mapped memory you can use more than 32 GB.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

Create one environment variable with following parameter/values :

varible name = JAVA_OPTS

variable value = -Xmx1000M -XX:MaxPermSize=512m
Nirmal
  • 4,789
  • 13
  • 72
  • 114