openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <ppod...@bea.com>
Subject RE: PCRegistry ClassLoader memory leak
Date Mon, 16 Jul 2007 22:43:14 GMT
Meta.fieldTypes is declared as Class[]. 
They are accessed via PCRegistry::getFieldTypes(Class pcClass).

The suggestion of "Change fieldTypes to be Strings instead" *perhaps*
meant to change Meta.fieldTypes to String[] (as field type names). And
only during
PCRegistry::getFieldTypes() 'lazily' converting the String[]s to
Class[]es (by the same ClassLoader of the PersistenceCapable class?).


 
 


Pinaki Poddar
972.834.2865

-----Original Message-----
From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On Behalf Of
Marc Prud'hommeaux
Sent: Monday, July 16, 2007 5:37 PM
To: dev@openjpa.apache.org
Subject: Re: PCRegistry ClassLoader memory leak


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 <plinskey@gmail.com> 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


Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message