Issue Details (XML | Word | Printable)

Key: OPENJPA-285
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Kevin Sutter
Reporter: Pinaki Poddar
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
OpenJPA

Multiple deploy/undeploy leaks memory in PCRegistry

Created: 17/Jul/07 06:29 AM   Updated: 01/Aug/07 10:05 PM
Return to search
Component/s: kernel
Affects Version/s: 1.0.0
Fix Version/s: 1.0.0

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works ImplHelperClassLoaderMemoryLeak.patch 2007-07-28 08:38 PM Kevan Miller 0.8 kB
Text File JIRA-285.patch.2.txt 2007-07-17 05:45 PM Pinaki Poddar 5 kB
Text File JIRA-285.patch.txt 2007-07-17 06:35 AM Pinaki Poddar 7 kB
Text File Licensed for inclusion in ASF works PCRegistryClassLoaderMemoryLeak.patch 2007-07-28 08:30 PM Kevan Miller 1 kB
Environment: Geronimo 2.0

Resolution Date: 01/Aug/07 10:03 PM


 Description  « Hide
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)


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Pinaki Poddar made changes - 17/Jul/07 06:35 AM
Field Original Value New Value
Attachment JIRA-285.patch.txt [ 12361957 ]
Pinaki Poddar made changes - 17/Jul/07 05:45 PM
Attachment JIRA-285.patch.2.txt [ 12361993 ]
Kevan Miller made changes - 28/Jul/07 08:30 PM
Attachment PCRegistryClassLoaderMemoryLeak.patch [ 12362726 ]
Kevan Miller made changes - 28/Jul/07 08:38 PM
Attachment ImplHelperClassLoaderMemoryLeak.patch [ 12362727 ]
Donald Woods made changes - 01/Aug/07 05:08 AM
Environment Geronimo Geronimo 2.0
Affects Version/s 1.0.0 [ 12312341 ]
Kevin Sutter made changes - 01/Aug/07 10:01 PM
Assignee Kevin Sutter [ kwsutter ]
Kevin Sutter made changes - 01/Aug/07 10:03 PM
Resolution Fixed [ 1 ]
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 1.0.0 [ 12312341 ]