バイトコードライブラリとJUnitとメモリリーク

http://d.hatena.ne.jp/t-katochin/20060623#1151082516
http://d.hatena.ne.jp/koichik/20060626#1151341237
http://d.hatena.ne.jp/t-katochin/20060627#1151410963
実は自分のところでも、S2TestCaseで大量のTestCaseを実行するとメモリリークで止まってしまうという問題が起こっており、悩んでいました。原因が掴めず、とりあえずパッケージ毎に手動で実行したりして、しのいでいたのですが・・・今回のお二方の日記を読んで、早速自分の環境でも試してみました。
SVNから最新のSeasar2・S2Tigerをチェックアウトして試してみたのですが・・・メモリリークは解消されませんでした。ClassLoader周りを重点的に調べていたところ、どうやらHibernateのBytecodeProviderが原因っぽいということがわかりました。
Seasarでは初期化のときに取得したコンテキストクラスローダを使ってAOPを利用したクラスが作成されるので、利用したクラスローダへの参照がなくなればAOPを利用したクラスはGCされていました。しかしHibernateのBytecodeProviderは、元クラスからClassLoaderを受け取り、それを使って新たなクラスを作成しているみたいです（Javassistの場合、ProxyFactoryのgetClassLoaderメソッド）。CLASSPATH上のクラスはシステムクラスローダからロードされますから、Hibernateで作成するクラスもシステムクラスローダで作成されてしまい、GCされずにテストケースを実行する毎にどんどんクラスが増えていき、最終的にはメモリ不足で止まってしまう・・・どうやらこういう現象が起こっているっぽいです。テスト環境用にHibernateのクラスを修正して対応できないだろうかと思ったのですが、クラス間の関係が密結合すぎて（苦笑）、独自の継承クラスを挟み込む隙がありません（汗）
これってつまり、Entity関連をロードするクラスローダを分ける必要があるってことかな？・・・ClassLoader周りは勉強をサボっていたので、今頃になってしっぺ返しを食らう羽目になりました。
Hibernateを使ってJUnitでテストしたら、少なからずこの現象が起こりそうなものですが・・・もしかして、普通はstaticフィールドにSessionFactoryを置いて、テストケースは全て同一のSessionFactoryを使用していることが多いのでしょうか？
AOP、O/Rマッパーに限らず、今後Javassistのようなバイトコードライブラリを使う機会はどんどん増えていくと思うので、作成したクラスをしっかりGCさせるような意識を強めなければならない・・・ということでしょうか。