In reply to @connorbaker:matrix.org
Sorry, I should have disambiguated -- Boehm GC

In reply to @connorbaker:matrix.org
I’ll post a small reproducer tomorrow of unexpected behavior I’m seeing with respect to the GC not freeing memory when I think it should be able to; I’d love to hear people’s thoughts on what could be causing it!

That would be great to see. Honestly it’d be nice to actually hunker down and write the tooling that we need for GC debugging/visualization. Hit me up if you would like to work on that.

How’s the Immer thing going btw?

In reply to @fzakaria:one.ems.host
Also, CLion to debug live Nix has been amazing; unfortunately the GoogleTest integration doesn't work -- doesn't seem to hydrate the "Target"

I've got a file temp.nix with this expression:

let
  numClosures = 1;
  nixpkgsPath =
    (builtins.getFlake "github:NixOS/nixpkgs/42a63d6a63c0ae7d715e46450fe5a5f69394525d").outPath;
in
builtins.genList (
  _:
  let
    drvPath' = (import (nixpkgsPath + "/nixos/release.nix") { }).closures.gnome.x86_64-linux.drvPath;
  in
  builtins.deepSeq drvPath' drvPath'
) numClosures

I ran nix eval by way of

/usr/bin/env time -v env GC_INITIAL_HEAP_SIZE=512M GC_MAXIMUM_HEAP_SIZE=512M GC_PRINT_STATS=1 NIX_SHOW_STATS=1 nix eval --json --expr "$(cat temp.nix)"

and kept lowering the maximum GC size until it would OOM with a numClosures = 1 (that's how I arrived at 512M). My expectation is that 512M should be sufficient to evaluate many copies of that closure, given I'm taking only the drvPath, and the only increase in memory usage I'd expect between the first and second evaluation of the closure is that the evaluator has allocated memory for the list of derivations it's going to print as JSON. However, when I use numClosures = 2, I OOM. Keeping everything same, I bumped it up to 1G of memory, and I still OOM with numClosures = 2.

One thing which could be tested is to create a large expression in the same fashion, without using import, to see if that has a different memory profile.