Fwd: Massive memory usage in BeanShell not GC'ing
Stewart Cambridge <[email protected]> Mon, 5 Oct 2009 11:53:02 +0100
| Newsgroups | gmane.comp.java.beanshell.user |
|---|---|
| Message-ID | <[email protected]> |
Hi Nirmal, Maybe this thread from 2006 will help. ---------- Forwarded message ---------- From: Stewart Cambridge <[email protected]> Date: 2008/10/21 Subject: Fwd: [Beanshell-users] Massive memory usage in BeanShell not GC'ing To: Atul Bisaria <[email protected]>, beanshell-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Cc: "David A. Lee" <[email protected]> Hi Atul, Check out this thread from 2006 ... ---------- Forwarded message ---------- From: Stewart Cambridge <[email protected]> Date: 2006/9/26 Subject: Re: [Beanshell-users] Massive memory usage in BeanShell not GC'ing To: David Lee <[email protected]> http://groups.google.co.uk/group/comp.lang.java.programmer/browse_thread/th= read/5142bb824b09e544/ea06d4d7205a24a8 It is the recursive self-references which cause the hang up. The solution I use is that whatever is holding a reference to the interpreter has to manually clean up, before it is destroyed itself. Basically this is a wrapper class around the interpreter object. protected void finalize() { =A0if( this.interpreter !=3D null ) =A0{ =A0 =A0this.interpreter.getNameSpace().clear(); =A0 =A0this.interpreter =3D null; =A0} } HTH On second thoughts, maybe the this should be code in the Interpreter class itself, and patched onto Beanshell itself? protected void finalize() { =A0 =A0this.getNameSpace().clear(); } On 26/09/06, David Lee <[email protected]> wrote: > > > I'm running into what looks like a similar case to Stewart 's =A0post 2 m= onths > ago about BeanShell and GC. > Unlike Stewart I have not yet been able to isolate it to a simple case ... > but its very clear. > I'm calling massive numbers of =A0either eval() or BshMethod.invoke() ...= and > the memory usage is going through the roof until I run out of VM and cras= h. > =A0I've tried every trick I can think of to no avail. > Unreferencing the Interpreter instances does not allow the GC to reclaim > memory !!! > I've moved references which may cycle back to "this" into thread local > storage, and string indexed maps outside the interpreter in hopes that the > problem would go away ... no go. > > If I cant find a solution to this I may have to rip out BeanShell and > replace it with something else ... what ? I don't know ... maybe pure java > with javac ... yuck yuck yuck ... > > I didn't notice this problem earlier and now of course its getting close = to > deadline :( > Earlier I tested with hundreds of calls and the memory use was reasonable, > but when I scale up to say 100,000 eval() or BshMethod.Invoke calls, which > in turn call into my code ... it eats up 200mb+ very quickly and the only > recourse is killing the java process and starting over ... > > Any suggestions at all on where I could look to possibly work around this > issue are greatly appreciated. > > Thanks > > ------------------------------------------------ > David A. Lee > VP Engineering > Nexstra, Inc. > dlee-qNp/[email protected] > www.nexstra.com > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > > _______________________________________________ > Beanshell-users mailing list > Beanshell-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/beanshell-users > > > ---------------------------------------------------------------------------= --- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay = ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf