[Biojava-dev] DP memory leak

[Lachlan James Coin]

I wasn't sure if there was enough consensus to commit my changes, so I 
haven't fixed anything yet:
 - adding a deregisterAlphabet(name) method to AlphabetManager and 
calling this from finalize in SimpleMarkovModel
- making alphabetToIndex a WeakHashMap  (I'm not 100% sure that this is 
OK with regard to standard alphabets)


Lachlan




Thomas Down wrote:

>Did this problem ever get fixed?  I've got a DP application
>leaking pretty badly right now.
>
>If the answer is no, would anyone object to me implementing
>the weak-reference solution? (which might require a little
>bit of magic so that the `well known' alphabets don't get
>unloaded immediately after BJ initializes.  *sigh*).
>
>     Thomas.
>
>Once upon a time, Matthew Pocock wrote:
>  
>
>>Hi,
>>
>>Lachlan James Coin wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I came across a bit of a memory leak while using the dp code.  The 
>>>problem is that AlphabetManager keeps a reference to every alphabet 
>>>created, including StateAlphabetcreated when using the dp package.  I 
>>>had extended the EmissionState class in such a way that the instances 
>>>were of a non-trivial size.  I am also creating (one after the other) 
>>>a lot of different state alphabets.  The result was that I ran out of 
>>>memory farily quickly.
>>>      
>>>
>>Hehe. That's an unforseen use-case bug.
>>
>>    
>>
>>>One possible fix I thought of was to add "deregisterAlphabet(name)" 
>>>method to AlphabetManager, and to call this from the finalize mehod of 
>>>SimpleMarkovModel, so that when the garbage collector thinks it can 
>>>clear the markov model the statealphabet is removed from the 
>>>AlphabetManager registry and can then also be garbage collected.   
>>>Also, it would be necessary to make alphabetToIndex a WeakHashMap.
>>>      
>>>
>>This may work - but it adds API.
>>
>>    
>>
>>>Any other suggestions?  Can I make these changes?
>>>      
>>>
>>How transparent can we make this? How easy would it be for alphabets to 
>>be dropped automatically when not needed any more? I guess we don't want 
>>to drop DNA & friends :)
>>
>>    
>>
>>>Thanks,
>>>
>>>Lachlan
>>>
>>>      
>>>
>>Matthew
>>
>>_______________________________________________
>>biojava-dev mailing list
>>biojava-dev at biojava.org
>>http://biojava.org/mailman/listinfo/biojava-dev
>>    
>>
>
>  
>