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&reg; 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&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf