Space leak in the run-time system? (due to CGC / scheduler?)

[shwestrick]

Running Forthoney/paregex:71809eebad6e5e202b4d95c1f83533cf4f537a73 on a single core seems to show a CGC space leak:

# ... git clone paregex @ 71809eebad6e5e202b4d95c1f83533cf4f537a73 ...

$ cd paregex
$ mpl -default-type int64 -default-type word64 -output main regex.mlb
$ ./main @mpl procs 1 log-level cc-collection:info log-file out.log -- '((ab(be|ke*)?){2058})+ag|(abek3k*){2857}|(alabama|wisconsin|hello|rhodeisland){2500}'
$ cat out.log | grep "num pinned after filter: "

This benchmark runs a very small parallel computation many times, back-to-back. This triggers a large number of CGCs. In the log, we can see that the number of pinned objects is increasing. We seem to be getting exactly one additional pinned object per CGC.

This is a single-processor execution, so it is easily reproducible.

Pinning has always been a messy component of the CGC; perhaps there is a bug lurking in there somewhere...

AFAICT, the source program itself does not have a space leak. It would be helpful to confirm this. (We could run different numbers of iterations with MLton to double check that the max footprint doesn't increase with the iteration count.)