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