Algorithms that lead to java.lang.OutOfMemoryError: PermGen space error

Question

I get a PermGen space error on the Sun JVM (1.6.0_21-b06) (Okay, this is Oracle :)). Increasing the -XX option: MaxPermGen value does not help. I know that PermGen is a space intended for persistent objects such as class metadata. The number of classes in the project is not so large ~ 10,000. Before the failure, jvisualvm shows 57MB as used by PermGen.

I guess some kind of algorithm takes up all the available memory. Does anyone know examples of algorithms that lead to PermGen overflow?

UPD I ask such an abstract question, because at the moment when I cannot use any profiler, the code crashes so badly that jvisualvm and eclipse stop responding. I need something to kill java processes from the terminal with kill -KILL {process_numer}. I work with poorly organized (but commercial) code that has many JMS threads and messages. Debugging is a mess - I first need to figure out where to look.

Answer 1

Does anyone know examples of algorithms that lead to PermGen overflow?

Yes, but what is the point of this? if you want to fix this, install a memory profiling tool like jprobe or lambda probe and check where the memory leak is and fix it. Now for an example: There are thousands of ways to exceed the gen space. I noticed in the project when we inherited the application in which they used JMS. The jms connections were left open, the application crashed within a few minutes after it had a lot of requests with the same error as you get. Please note: when we switched to weblogic from jboss (moved to beajrockit), surprisingly, he corrected himself or at least accepted the blow of technical debt. My advice would be regardless of this, bad code with memory leaks should be fixed first, and then mess with application servers and heap space allocation parameters.

Here is a useful link with some exception information you get. http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang

EDIT

This link may be useful http://www.precisejava.com/javaperf/j2ee/JMS.htm

Answer 2

This is not so much an algorithm as an implementation. Here's a really dumb way to generate random strings that fill the PermGen space:

Random rnd = new Random(); List<String> interned = new ArrayList<String>(); for (;;) { int length = rnd.nextInt(100); StringBuilder builder = new StringBuilder(); String chars = "abcdefghijklmnopqrstuvwxyz"; for ( int i = 0; i < length; i++ ) { builder.append(chars.charAt(rnd.nextInt(chars.length()))); } interned.add(builder.toString().intern()); } 

In short, string interning is one thing PermGen memory can eat.

Answer 3

There are two things that can lead to PermGen space issues:

• The String.intern(String) method creates strings in the PermGen heap. If you practice a lot and directly (or indirectly) keep links to interned strings, you can fill out PermGen.

• Class loaders create JVM inner class descriptors and code segments on the PermGen heap. If your application performs a large dynamic loading of classes, and class objects do not collect garbage, you can fill in PermGen.

Hot Swapping Java Webapps is based on dynamic loading and is a common source of PermGen problems. The main reason is a memory leak, which includes a hidden link from some object to the old classloader. (Tomcat often gets a “stick” for this, but the real problem usually arises in the webapp, which is redistributed.)

AFAIK, the Proxy application mentioned by @Michael Borgwardt, is also the result of implementing proxy generation class files and loading them on the fly.

Answer 4

If you use java.lang.reflect.Proxy very intensively, it can also eat PermGen space.

Answer 5

Check out the memory analyzer - http://www.eclipse.org/mat/ . This is a Java dump memory analyzer. This is very useful after an unexpected error.

Answer 6

Are you using a different garbage collector?

The throughput collector will throw an exception in memory if too much time is spent on garbage collection. For example, if the JVM spends more than 98% of the total time collecting garbage and restores less than 2% of the heap, it erases the deletion from memory. The implementation of this function has changed in 1.5. The policy is the same, but there may be slight differences in behavior due to the new implementation. "" In the J2SE platform version 1.5, the bandwidth collector will be selected as the garbage collector on the server class machines. " Http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Check out some of the instructions on this page.