0005932: Modules can leak memory

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0005932

OCaml

OCaml backend (code generation)

public

2013-02-25 02:58

2013-02-25 09:43

Reporter

mottl

Assigned To

frisch

Priority

normal

Severity

major

Reproducibility

always

Status

resolved

Resolution

duplicate

Platform

OS Version

Product Version

4.00.1

Target Version

Fixed in Version

Summary

0005932: Modules can leak memory

Description

Though this issue is particularly important with first-class modules, because they are much more frequently allocated and may stay around for a long time, this seems to be a general issue with module code. Here is an example where first-class modules leak memory:

-----
module type S = sig val x : int end

module type T = sig
  include S (* swap *)
  val y : string (* swap *)
end

let copy (module M : T) = (module M : S)

let alloc () =
  copy (module struct
      let x = 42
      let y = String.create 100_000_000
    end : T)

let main () =
  let m = alloc () in
  Gc.full_major ();
  Gc.print_stat stdout;
  m

let () = ignore (main ())
-----

The GC stats (live words) printed by this example show that even after a full major collection the string "y" in an allocated module stays around after the signature of the module has been constrained to not contain "y" in a presumed copy of the original module. If you swap the two lines marked by the comment "swap" in the above code, the problem goes away, because the compiler is forced to reallocate the constrained module due to a different memory layout and can hence "forget" "y".

The assembly code shows that in the first (buggy) case the compiler merely returns the pointer to the original module in the "copy" function. That's sound in the sense that there will not be a segfault if the target signature is a "prefix" of the source signature. But this will, of course, leak memory. The compiler will correctly allocate a fresh, "smaller" module if the target signature is not a "prefix" of the source.

One could argue that this behavior may be acceptable with file modules, because they have a more "static" feel. But I don't think this is acceptable with first-class or even local modules. Values that have been "constrained away" should not only be inaccessible, they should also be reclaimed by the GC.

Notes
(0008911) frisch (developer) 2013-02-25 09:43	Closing, as this is a duplicate of 0005098.

Issue History
Date Modified	Username	Field	Change
2013-02-25 02:58	mottl	New Issue
2013-02-25 09:42	frisch	Relationship added	duplicate of 0005098
2013-02-25 09:43	frisch	Note Added: 0008911
2013-02-25 09:43	frisch	Status	new => resolved
2013-02-25 09:43	frisch	Resolution	open => duplicate
2013-02-25 09:43	frisch	Assigned To	=> frisch