0

We have an application that generates thousands of Java ClassLoaders and classes, before letting them be garbage collected. We are pretty sure there is no class loader leak, but we are getting permgen errors (and even if there is, this question is orthogonal to any potential leak).

Is there any way of specifying that certain ClassLoaders and their loaded classes are placed in the heap rather than in perm gen?

We are using the Oracle JDK Java 6 on Linux.

Edit: Looks like Java 8 will no longer have PermGen. It will be replaced by Metaspace.

http://java.dzone.com/articles/java-8-permgen-metaspace

Andrew Eisenberg
  • 28,387
  • 9
  • 92
  • 148

2 Answers2

2

Of course you're getting perm gen errors - that's where class loaders put classes. What would you expect?

You can map them into byte buffers, like Java NIO does it, but they don't go on the heap.

You ought to try increasing your perm gen size before taking extraordinary measures. How much perm gen space do you need? Profile it using Visual VM and see.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Thanks. "Of course you're getting perm gen errors - that's where class loaders put classes. What would you expect?" I know that and that is why I am asking this question. If these objects can be put in regular memory, then we won't get permgen errors (we might get heap errors, and that might help solve our problem). We currently use 385M of PermGen and I don't think increasing any more is a good idea. As I said, there may be a leak and we have spent the last couple of days looking for it using Visual VM and YourKit. Things might be easier to track down if we had heap errors instead of permgen. – Andrew Eisenberg Mar 20 '13 at 22:57
  • Not really. Memory is memory - the subdivisions into generations is a GC/memory model design choice. Why is increasing it not a good idea? If you had heap errors, would it be an equally bad idea to increase heap? This whole approach is wrong headed. – duffymo Mar 21 '13 at 00:05
1

Is there any way of specifying that certain ClassLoaders and their loaded classes are placed in the heap rather than in perm gen?

AFAIK, there is no way to do that. AFAIK, the permgen allocation happens deep in the JVM runtime where you can't get at it. (I don't think that the classloader itself is in permgen. I think it is just certain of the JVM's internal data structures that represent the classes and their code.)

If your application really has to work that way, I think you have no choice but to make permgen large enough. (Obviously, you should also check that the real problem isn't a permgen leak.)

However, it strikes me that your application's architecture is rather strange if it needs to generate lots of classes and class loaders. I'd look to see if what it is doing couldn't be done another way.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Yes, the application's architecture is very strange. I would love to restructure things to be a different way, but this is for grails-ide that needs to run hundreds of tests that create, compile, run and destroy grails projects. Grails uses Groovy, and Groovy uses custom classloaders to load and compile its scripts. Thanks for the advice. We'll keep looking. – Andrew Eisenberg Mar 20 '13 at 23:36
  • Sounds like it's time to dump Grails. I had no idea it was this bad. Thanks for the heads up. – duffymo Mar 21 '13 at 00:06
  • That comment may have come out wrong. Grails works great from a user's standpoint. The custom classloaders for compilation makes sense when you run a grails command and then exit. The problem we are having now is permgen problems in our test suite for the IDE since we need to execute hundreds of commands in the same process. – Andrew Eisenberg Mar 21 '13 at 03:43
  • @AndrewEisenberg - OK ... so that >>is<< a peculiar use-case. I suggest that you partition your test suite and run the parts in different JVMs. – Stephen C Mar 21 '13 at 04:56