openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevan Miller (JIRA)" <j...@apache.org>
Subject [jira] Updated: (OPENJPA-285) Multiple deploy/undeploy leaks memory in PCRegistry
Date Sat, 28 Jul 2007 20:30:52 GMT

     [ 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.


Mime
View raw message