Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lazy expressions are not garbage collected #3799

Closed
vicuna opened this issue Sep 28, 2005 · 4 comments
Closed

Lazy expressions are not garbage collected #3799

vicuna opened this issue Sep 28, 2005 · 4 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Sep 28, 2005

Original bug ID: 3799
Reporter: administrator
Status: closed (set by @damiendoligez on 2005-12-15T13:18:26Z)
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: yoann padioleau
Version: 3.08.3
OS: linux
Submission from: nat5.emn.fr (193.54.76.165)

I had a function f1 that produce a list of big structures (AST of C files)
and a function f2 that do some global processing on this list (via a
List.iter).

let f1 list_c_files =
List.map (fun file -> <read_AST_file_via_marshall_module>) list_of_c_files

let f2 xs = List.iter (fun ast -> <do_some_stuff> ) xs

As executing first f1 requires too much memory, because it requires to put all
AST in memory, I decided to produced the AST lazyly by generating
a list of (AST Lazy.t)

let f1 list_c_files =
List.map (fun file -> lazy (<read_AST_....>) list_of_c_files

let f2 xs = List.iter (fun lazyast -> let ast = Lazy.force lazyast in
<do_some_stuff>) xs

But doing that did not solve the problem. My program still consume too much
memory.
I imagined that perhaps because you maintain under the hood some global
variables so that when someone else do Lazy.force x on a x that
has already been forced, you don't redo the computation.

So I replaced your lazy module by my own, simple, lazy module.
type 'a mylazy = unit -> 'a

so I have

let f1 list_c_files =
List.map (fun file -> (fun () -> <read_AST>)) list_c_files

let f2 xs = List.iter (fun mylazyast -> let ast = mylazyast() in <do_some>) xs

AND IT WORKS. I have no more problem of memory.
The not-any-more-used AST are garbage collected.

So I guess maybe there is a bug in your lazy module, or that
perhaps it is a feature, but perhaps such "bad" behaviour should
be documented.

@vicuna
Copy link
Author

vicuna commented Oct 12, 2005

Comment author: administrator

I imagined that perhaps because you maintain under the hood some global
variables so that when someone else do Lazy.force x on a x that
has already been forced, you don't redo the computation.
So I replaced your lazy module by my own, simple, lazy module.
type 'a mylazy = unit -> 'a
AND IT WORKS. I have no more problem of memory.
The not-any-more-used AST are garbage collected.

So I guess maybe there is a bug in your lazy module, or that
perhaps it is a feature, but perhaps such "bad" behaviour should
be documented.

I'm positive that lazy expressions are GCed like any other. Could you
send a program that reproduces the issue? Thanks,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Oct 12, 2005

Comment author: administrator

Waiting for repro case

@vicuna
Copy link
Author

vicuna commented Nov 20, 2005

Comment author: anonymous

delayed evaluation and weak values are separate things.

One could probably write a "WeakLazy" module that saves evaluated expressions as weak values, and keep the embedded continuation around to re-evaluate Gc'ed values. It could lead to unexpected results if the contination does side-effects, however.

@vicuna
Copy link
Author

vicuna commented Nov 22, 2005

Comment author: @damiendoligez

The program is probably keeping a pointer to the list of lazy values.
Lazy evaluation is not the same as call-by-name.

-- Damien

@vicuna vicuna closed this as completed Dec 15, 2005
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant