From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16312; Sun, 13 Oct 2002 10:33:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA15923 for ; Sun, 13 Oct 2002 10:33:05 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g9D8WO517213; Sun, 13 Oct 2002 10:32:24 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16301; Sun, 13 Oct 2002 10:32:23 +0200 (MET DST) Date: Sun, 13 Oct 2002 10:32:23 +0200 From: Xavier Leroy To: Chris Hecker Cc: caml-list@inria.fr, buzzard@nothings.org Subject: Re: [Caml-list] gc question: thread stacks, fibers, etc. Message-ID: <20021013103223.E13771@pauillac.inria.fr> References: <4.3.2.7.2.20021004000748.030bd2c0@mail.d6.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.3.2.7.2.20021004000748.030bd2c0@mail.d6.com>; from checker@d6.com on Fri, Oct 04, 2002 at 03:25:44AM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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