Re: [Caml-list] gc question: thread stacks, fibers, etc.

[Xavier Leroy <xavier.leroy@inria.fr>]

> Is there a way to make the stack just another heap object?  I could easily 
> put the pointer to the stack in an Abstract_tag block, but then the stack 
> won't get scanned by the gc at all, which is bad.

I'm not sure whether you're talking about bytecode stacks or
native-code stacks.  For bytecode stacks, all stack slots contain
valid Caml values, hence you could conceptually store the stack in a
zero-tagged block and let the GC scan it.  There are several
"gotchas", though:
- The GC will scan the whole memory block, not stopping at the stack
pointer.  Hence, some stack slots that have been popped already will
be treated as live pointers, delaying the collection of otherwise dead
blocks.
- Exception handler blocks in the stack are chained using direct
pointers.  Hence, relocating the stack (like the minor copying
collector and the heap compactor do) will screw this chaining.

Native-code stacks are much more complex and absolutely require a
special scanning function that interprets the stack frame maps
generated by ocamlopt.

> It seems like what I 
> want is another kind of block or another function in the custom_operations 
> for "let me manually scan the opaque data in this block, which itself 
> points to data that contains values, and if it's all garbage, finalize me".

This is one way to go about your problem, but such custom scanning
functions are not currently supported.

An alternative is to allocate the stack outside the heap, and scan it
via scanning hooks like the thread library does, but manipulate it
from the Caml side through a proxy, heap-allocated custom block.  The
custom block has a finalization function that the GC will call when no
reference to the proxy (i.e. to the fiber) remain.  The finalization
function can then decide to kill the fiber (free its stack) if it so
pleases.

> My next question is a clarification of the way caml works:  the stack can 
> contain values, but never blocks, right?  In C terms, it can contain 
> pointers but not actual objects that other people can point to?  All actual 
> boxed data is on the heap, right?  So, I can just delete a fiber's stack 
> and it'll work?  

Correct.  OCaml never allocates GCed memory blocks in the stack, hence
there are no pointers from the heap into the stack.

> Finally, a couple confusions:
> - final_fun in caml_thread_handle in win32.c is not used?

It is just a placeholder where alloc_final will store a pointer to a
finalization function (caml_thread_finalize).  This should be
rewritten to use the new "custom blocks" API.

> - HANDLE in caml_thread_handle in win32 seems odd, since it's scanned by 
> the gc, yet it's a windows handle.

No, it's not scanned by the GC because it resides in a block with tag
Custom_tag.

Hope this answers your questions,

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners