openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <>
Subject Re: PCRegistry ClassLoader memory leak
Date Mon, 16 Jul 2007 22:36:34 GMT

I'm a little unclear about what "Change fieldTypes to be Strings  
instead" means. Do you mean the key in the map, or something?

One other solution would be to get rid of the Map and just use some  
sort of weak Set, but lookups would need to iterate through the set  
every time. I don't know what kind of performance hit this would incur.

The best solution would probably to just eliminate this (and all) non- 
constant static fields. I remember trying very hard to do this some  
time ago, but I kept hitting walls preventing the complete  
elimination. Maybe smarter minds than me can figure it out, though.

On Jul 16, 2007, at 3:17 PM, robert burrell donkin wrote:

> On 7/16/07, Patrick Linskey <> wrote:
>> > Anyone have any ideas?
>> Change fieldTypes to be Strings instead, and dematerialize them as  
>> needed.
> after spending hundreds of hours pursuing other solutions to a similar
> issue, i that this would be wise.
> <rant>
> sounds very similar to the infamous commons logging leak. after a
> *lot* of work, Brian Stansberry wrote a custom hashtable
> implementation which (after a lot of testing and rewriting) didn't
> seem to leak with modern JVMs. we used reference queues and periodic
> purging.
> IMO the real problem is that the J2EE specification lacks application
> life cycle events. i've heard of other leaks (eg when using
> reflection) which are hard or impossible to fix. of course, it doesn't
> help that the classloader specifications are broke too...
> </rant>
> - robert

View raw message