[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [javaflow] Stack class
From:       Torsten Curdt <tcurdt () apache ! org>
Date:       2005-07-31 23:06:39
Message-ID: B9054C15-1D7D-4FF0-9C80-F2A58755C3DD () apache ! org
[Download RAW message or body]


> 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


["PGP.sig" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]