From: Xavier Leroy <xavier.leroy@inria.fr>
To: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] GC Question
Date: Thu, 11 Sep 2003 17:04:22 +0200 [thread overview]
Message-ID: <20030911170422.A16344@pauillac.inria.fr> (raw)
In-Reply-To: <3F5CE84F.4030609@univ-savoie.fr>; from christophe.raffalli@univ-savoie.fr on Mon, Sep 08, 2003 at 10:36:31PM +0200
> in the following kind code :
>
> let l = ... a function building a long list ... in
> let l' = List.map fn l in (* or fold or anything similar *)
> ... no more reference to l ...
>
> Once the beginning of l has been read to compute l' (assuming List.map
> starts from the beginning of l) is the GC able to collect the beginning
> of l ?
Short answer: with ocamlc, no. With ocamlopt, yes.
Longer answer: in the bytecoded implementation, every value in the VM
stack is a GC root. "let x = e in e'" pushes the value of e on the
stack just before evaluating e', and pops it at the end of e'. So,
the value of e remains a live GC root throughout the evaluation of e'.
In the native-code implementation, not all machine stack entries are
GC roots, but only the stack slots that hold a variable of type
address that is live at the point where the GC is called. ("Live"
here is in the sense of liveness analysis of local variables.)
In your example, "l" is not live across the call to "List.map fn l".
> If not how to write the code to ensure this behaviour of the GC ?
As other mentioned, removing the outer "let" gives the desired GC
behavior even in bytecode:
List.map fn l (... list builder ...)
In the OCaml sources, you can find this strange-looking idiom:
let (++) x f = f x
Pparse.file ppf inputfile Parse.implementation ast_impl_magic_number
++ print_if ppf Clflags.dump_parsetree Printast.implementation
++ Typemod.type_implementation sourcefile prefixname modulename env
++ Translmod.transl_implementation modulename
++ print_if ppf Clflags.dump_rawlambda Printlambda.lambda
++ Simplif.simplify_lambda
++ print_if ppf Clflags.dump_lambda Printlambda.lambda
++ Bytegen.compile_implementation modulename
++ print_if ppf Clflags.dump_instr Printinstr.instrlist
++ Emitcode.to_file oc modulename;
which is a nicer way of writing
Emitcode.to_file oc modulename
(print_if ....
(Bytegen.compile_implementation ...
(print_if ...
(...
))))
and gives better GC behavior than the obvious:
let x1 = Pparse.file ppf inputfile Parse.implementation ast_impl_magic_number in
let x2 = print_if ppf Clflags.dump_parsetree Printast.implementation p x1 in
let x3 = Typemod.type_implementation sourcefile prefixname modulename env x2 in
...
- 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
next prev parent reply other threads:[~2003-09-11 15:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030820104917.GB6782@linux-m68k.org>
2003-08-20 12:32 ` [Caml-list] Native compiler support for m68k? Xavier Leroy
2003-08-20 17:46 ` Gleb N. Semenov
2003-08-21 14:56 ` Xavier Leroy
2003-08-21 19:32 ` Daniel M. Albro
2003-08-24 20:05 ` Richard Zidlicky
2003-08-26 13:43 ` Xavier Leroy
2003-08-30 9:59 ` Richard Zidlicky
2003-09-05 21:58 ` Richard Zidlicky
2003-09-06 0:53 ` Byron Hale
2003-09-06 10:01 ` Benjamin Geer
2003-09-07 13:37 ` David MENTRE
2003-09-08 9:52 ` Damien Doligez
2003-09-08 20:36 ` [Caml-list] GC Question Christophe Raffalli
2003-09-09 9:32 ` Pierre Weis
2003-09-09 10:40 ` Christophe Raffalli
2003-09-11 15:04 ` Xavier Leroy [this message]
2005-07-05 7:59 GC question dmitry grebeniuk
2005-07-06 7:29 ` [Caml-list] " Jean-Christophe Filliatre
2005-10-24 17:53 MATTHEW HAMMER
2005-10-25 18:41 ` [Caml-list] " Damien Doligez
2005-10-25 19:20 ` MATTHEW HAMMER
2005-10-27 14:25 ` Damien Doligez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030911170422.A16344@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=caml-list@inria.fr \
--cc=christophe.raffalli@univ-savoie.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox