Seamアプリの再デプロイを繰り返すと遅かれ早かれOutOfMemoryErrorが発生する

JBoss Seam

seam-genやJBossToolsはホットデプロイ機能を特徴のひとつとしているため、最初は信じがたいのですが、どこかでクラスローダーリークが発生しているらしくSeamアプリの再デプロイを繰り返しているといつかOutOfMemoryErrorが発生します。よって、定期的にサーバーVMの強制終了と再起動を行う必要があります。
http://seamframework.org/20882.lace
上記のスレッドではSunのVMのバグだとか、

-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

というおまじないをVM起動パラメーターにつけると問題が避けられるなどという議論もありますが、私がJConsoleを使ってメモリーの使用状況を確認したところでは、少なくともJBoss AS5.1に対して再デプロイを繰り返すと、確実にPermGen領域が食いつぶされていくことがわかりました。（もちろん自動生成した雛形コードに対してです。）
クラスローダーリークは、階層クラスローダーの仕組みによるもので、親のクラスローダーが子供のクラスローダーで読み込まれたクラスの強参照をひとつでも保持している限り、決して子供のクラスローダーが解放されず、アンデプロイしてもクラス定義がすべてメモリー上に残存してしまう現象です。主な原因については、以下が参考になります。

http://www.slideshare.net/nekop/classloader-leak-patterns
http://opensource.atlassian.com/confluence/spring/display/DISC/Memory+leak+-+classloader+won't+let+go
普通のメモリーリークと違って原因を突き止めるの非常に困難でまた、再デプロイを繰り返さない限り問題とはならないため放置されることが多いようですが、開発生産性を大きく下げる原因となり得ます。
通常、JBossではHibernateやcglibがアプリのローダーでなくサーバーのクラスローダーで読み込まれる構成となるためクラスローダーリークが発生しやすいのだと思います。 アジャイル開発にはかなりの障害なのですが、今のところヒープメモリーやMaxPermSizeを大きめに確保して、エラーの頻度を下げるくらいしか方法がありません。いろいろなライブラリーの組み合わせになっているSeamの場合、特に問題を突き止めるのが難しいのでしょうか？
結局Seamで生産性を高めるには、再起動の時間の速いサーバーを利用するということになると思います。