[
https://issues.apache.org/jira/browse/OPENJPA-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller updated OPENJPA-285:
---------------------------------
Attachment: PCRegistryClassLoaderMemoryLeak.patch
I'm attaching a potential fix for this problem. It adds a
PCRegistry.deRegister(ClassLoader) method. It allows Geronimo to inform OpenJPA
when a ClassLoader is no longer valid. deRegister() simply iterates through all
entries in the _metas map and removes all entries whose keys were loaded by the
associated ClassLoader. If you don't like iterating though all of the _metas
tables, it's a simple matter to maintain a set of Classes associated with each
ClassLoader. I like the simplicity of it iterating. ClassLoaders are removed on
an infrequent basis.
I've tested this change along with associated Geronimo changes in
https://issues.apache.org/jira/browse/GERONIMO-3326. I've been through 100's of
deploy/undeploy cycles without a problem...
The problem with other solutions (WeakReferences or Stringified Class names) is
that PCRegistry$Meta.pc must be a hard reference. It is your only reference to
the PersistenceCapable object. If it is a WeakReference, the PersistenceCapable
object will be GC'ed and bad things start to happen... ;-)
There's one other solution, which could be considered: Allow embedders to be
notified when you've created PersistenceCapable objects. Embedders could
maintain the strong references to these objects and delete the references when
a ClassLoader has been deleted. PCRegistry references could then be
WeakReferences.
> Multiple deploy/undeploy leaks memory in PCRegistry
> ---------------------------------------------------
>
> Key: OPENJPA-285
> URL: https://issues.apache.org/jira/browse/OPENJPA-285
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Environment: Geronimo
> Reporter: Pinaki Poddar
> Attachments: JIRA-285.patch.2.txt, JIRA-285.patch.txt,
> PCRegistryClassLoaderMemoryLeak.patch
>
>
> Kevin Miller reported:
> Geronimo is running out of PermGen space in some simple deploy/ undeploy
> scenarios involving OpenJPA. The cause of the problem seems to be the _metas
> table in PCRegistry. _metas is a ConcurrentReferenceHashMap with WEAK
> reference keys and HARD reference values. The keys are the PersistenceCapable
> classes. While the values are the metadata for these classes which are
> maintained by the internal Meta class.
> The cause of the ClassLoader memory leak is simple -- if any of the
> objects/classes held by the Meta class (e.g. fieldTypes) have also been
> loaded by the same ClassLoader used to load the PersistenceCapable class, the
> PersistenceCapable class (the weak key) will never be GCed. The value of the
> HashMap entry will always maintain a hard reference to the ClassLoader. Since
> the ClassLoader will never be GC'ed, the the the pcClass Class object will
> never be GC'able...
> The problem can be easily recreated using current Geronimo trunk and the
> Geronimo Daytrader application.
> Patrick Linskey suggested:
> Change PCRegistry.fieldTypes to be String[] instead of Class[], and
> dematerialize them as needed.
> Robert Burrell Donkin/Marc Prud'hommeaux both pointed out that alternatives
> such as to
> listen for the death of a ClassLoader and manually unregistering metadata
> would be more costly in terms of complexity.
> This patch follows Patrick's suggestion.
> 1. Changes the Meta.fieldTypes to String[] from Class[]
> 2. Adapts the enhanced bytecode accordingly to the modified method signatures
> 3. PCRegistry getFieldTypes() load the fields' declared type using the same
> loader that loaded the owner pc class.
> Note: For a class C and its field f, CL(c) == CL(f) is not always true.
> (Kevin Miller)
> But CL(c) will be able to load declared type of f either directly
> or via one of its parent (Craig Russel)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
