StackThreads and Phobos

[mclysenk at mtu.edu]

In article <e88ltq$kvc$3 at digitaldaemon.com>, Bruno Medeiros says...
>
>But isn't that the correct behavior? If one can return to that function 
>instance(context), shouldn't all allocations made previously by that 
>function remain valid?
>(note: I haven't used your library, I just read your post and this 
>question came up)
>

It is not correct behavior.  Here's an example which may illustrate this better:

#void func1()
#{
#     func2();
#     yield();
#}
#
#void func2()
#{
#     int[] arr = new int[20];
#}

Here is a trace of the execution of func1 alongside it's stack

# Instruction              |      Stack
#--------------------------+--------------
#  func2()                 | SP> &func1 + offset
#                          |
#  int[] arr = new int[20] |     &func1 + offset
#                          | SP> &arr
#                          |
#  return from func2()     | SP> &func1 + offset
#                          |     &arr             <-- Old unused reference
#                          |
#  yield()                 |     &func1 + offset
#                          |     &arr             <-- Will NEVER get collected
#                          |

In this situation, it is doubtful that arr will ever get collected.  In order
for the GC to remove it, it must not find ANY references to arr in memory.
Period.  If the GC scans the entire stack, it will see a reference to arr, and
therefore it will never collect arr.  This is a trivial example, but it is not
difficult to see that these sorts of memory leaks can become very substantial
and very difficult to track down.


The problem is how to tell the garbage collector not to scan past the stack
pointer.  The only way at the moment is to use addRange and removeRange, or zero
out all of the unused stack memory every time you yield.  Either option has a
substantial overhead.

>
>Also: Where do you keep the data from each context? In the heap?
>
>

Heap.  The next version of stackthreads will replace malloc/free with system
specific allocators, such as mmap and VirtualAlloc.

-Mikola Lysenko