NetBeans/Glassfish and PermGen space bug when redeploying (yes, STILL happening)

Question

I know this has probably been asked many times before, but I still haven't seen an actual fix for it.

My day-to-day development environment is as follows: 1. NetBeans (latest), 2. Glassfish (latest as bundled with NB), 3. JPA, JSF, JAXB, Jersey for JAX-RS

I have about 600 classes in my project, spread across two EJB projects and one WAR project, all inside an EAR.

I am on latest JDK 7 (on OS X) and I am on an hourly basis getting the infamous "PermGen space" bug. Let's say if I am doing 3 incremental re-deploys a minute, I can only work for a short while before either:

• Glassfish run out of PermGen space, so I just have to kill the process.
• Deployment becomes extremely slow, due to me having increase max permgen space (as one is advised to do from dozens of answers on S.O.)

Often the only solution is to kill glassfish every 30 minute or so. It's definitely due to a bug somewhere that simply loads new classes for every new incremental re-deploy instead of getting rid of the old ones. I thought this was supposed to be fixed in JDK 7?

This has been a long standing bug in the kind of development environment, and I am rather shocked that it's still going on after my 5+ years of Java development. It's just so frustrating and incredibly unproductive.

(Just before anyone suggests increasing permgen space, believe me I've tried that, and the only thing it "solves" is to prolong the inevitable. I've seen redeployments take up to 400 seconds at its worst. Redeployment is supposed to take 5-6 seconds for a project this size, no more.)

EDIT: I ran jmap and jhat on the Glassfish process after the following steps:

1. Start glassfish
2. Deploy my EA
3. Undeploy my EA
4. Then did a heap dump with jmap

It turns out that all my classes (which should have been unloaded) are still loaded! Hopefully this is useful information to someone reading this...

Answer 1

Surely, that is a bug, and I don't think that there is an easy solution for that. (If there were, probably you have had it already).

What you can try: Use some hot code replacement tool for example JRebel, This way you don't have to deploy all the time, instead this tool watches the changes of the .class files (and even other web resources, if you configure so), and replaces the class definition within the running JVM. Sounds cool, right?

It works as a Java agent, it starts when your JVM starts.

There are 3 drawbacks of this solution: The deployment is a bit slower, it's harder to debug, and it's a proprietary software (but does not cost much)

Answer 2

When developing with Netbeans + Glassfish and using "Deploy on Save" we've found that libraries packaged within an application are not unloaded when the project is re-deployed; this causes GF to slow down and quickly run out of memory.

Try de-selecting "Package" for all compile-time libraries and place those not already in the Glassfish classpath in the domainX/lib directory.

Not sure but this may be related to GLASSFISH-17449 or GLASSFISH-16283.