I'm using Hibernate 3.1.2, antlr-2.7.6rc1, and cglib-2.1_3, in short the currently recommended versions of everything. My java console-application (i.e. there's no web-container screwing things up here) is hitting an OutOfMemoryException. Using GC logs, I've determined that the exception is coming from the Perm space (not the heap) running out of memory (MaxPermSize left at 64m default). The implication here is that too many classes are being instantiated.

I've managed to trace this down to a modified parent-child relationship between two classes.

--------------------------------------------------------
Here's CHILD (note many-to-one)

<hibernate-mapping>
<class name="Child" table="Child" dynamic-update="true">
<meta attribute="implement-equals">true</meta>
<cache usage="read-only" />
<composite-id name="id" class="ChildKey">
<meta attribute="use-in-equals" >true</meta>
<key-property name="childID1" column="CHILD_ID1" type="java.lang.Long"/>
<key-property name="childID2" column="CHILD_ID2" type="java.lang.String"/>
</composite-id>

<many-to-one name="parent" column="PARENT_ID" class="Parent"
insert="false" update="false" lazy="proxy" unique="true"/>
</class>
</hibernate-mapping>

---------------------------------------------
Here's parent
<hibernate-mapping>
<class name="Parent" table="PARENT" dynamic-update="true">
<meta attribute="implement-equals">true</meta>
<cache usage="read-only" />
<id name="parentId" column="PARENT_ID" type="java.lang.String">
<meta attribute="use-in-equals" >true</meta>
<generator class="assigned"/>
</id>
</class>
</hibernate-mapping>

-----------------------------------
The class(es) get instantiated via:
Query query = session.createQuery("from Child as im where "
+ "im.id.childId1 = :id1 and im.id.childId2 = :id2");

query.setInteger("id1", <some number>);
query.setString("id2", <some string>);

List list = query.list();

-----------------------------------
When the program is run, the above query gets hit (once) and as a result, a number of Parent objects get created (reasonable given the code logic). Later, the session is closed and the expectation is that things would generally be cleaned up. However, when looking at things through a memory-profiler (JMP was used), I see that there are still instances of:
Parent$$EnhancerByCGLIB$$eb32f633$$FastClassByCGLIB$$f5868442
Parent$$FastClassByCGLIB$$24540430

Normally, this wouldn't be terribly problematic. However, when the next request comes in, a new Session is created and we again hit the above code thereby creating a second set of the above (the hex-codes change). Each request creates a new Session which causes a new set of the above. They are never garbage collected.

After enough requests, we finally create enough of the above classes to consume the entire Perm space and yield the OOM exception.

I'm hoping that it can be solved by fixing the mapping files, but I'm willing to consider any solution.