You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2005/08/01 01:06:39 UTC

Re: [javaflow] Stack class

> There are two key characteristics in the current Stack class:
>
> 1. an array may get bigger, but it will never get smaller, even  
> when a stack is copied, and even if the stack size shrinks.
> 2. popped objects won't be clobbered from an array.
>
> Therefore, once an object is recorded to ostack or rstack, the only  
> way for them to be removed is for the entry to be overwritten by  
> another object, but this may never happen (the stack size may never  
> grows back to the same size.) IOW, a Stack retain references to  
> objects even after they are popped (this alone is OK, as popped  
> objects are just copied into stack), and those unnecessary  
> references get copied to successive Stack objects created from it.  
> This causes memory leak for a long running "thread".
>
> The fix is actually easy, which is to change the copy constructor  
> of Stack so that it only copies the valid region of the parent array.

Sure ...makes sense.
Good finding!

> The only algorithm I can think of to do this require a lot of  
> additional local variables on each stack frame (6 ints to record  
> the stack top while Continuation1 is being restored --- we can use  
> this value while capturing Continuation2.)
>
> I don't know if this cost is worth the benefit. If the memory foot  
> print is a concern, maybe it's easier to capture all stack frames  
> first and then find the common part later. I suspect we need more  
> user experience.
>
> It's also bit tricky because Stacks will share their tops, not  
> their roots.

I know it's a bit tricky ...and
whether it's worth the hassle is
really the question.

But we can leave that for later ;)

cheers
--
Torsten


Re: [javaflow] Stack class

Posted by Kohsuke Kawaguchi <Ko...@Sun.COM>.
Torsten Curdt wrote:
> I know it's a bit tricky ...and
> whether it's worth the hassle is
> really the question.
> 
> But we can leave that for later ;)

Agreed.


-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@sun.com