Memory usage limiting to 0B on MacOS -> no compositions

[alexhunsley]

MacOS 15.6.1
rustc 1.88.0 (installed via homebrew)

I'm trying one of the samples verbatim: jadds-method.toml from this repo.

Nearly always I get 0 compositions output with Limiting memory usage to 0B reported (which would be the cause right?)

When I freed up some system memory, it works and I get mem allocated and comps generated.

I suggest if memory allocated is too small or zero, monument could flag up a low memory situation and exit with error.

Currently it's too easy to miss that low memory is the issue and then you hunt around your .toml looking for config issues that don't exist.

My repro:

❯ monument_cli jadds-method.toml
INFO  [monument_cli::music] Using default music.  If you want no music, set `base_music = "none"`.
INFO  [monument::search::best_first] Limiting memory usage to 0B
    5 iters, 0 comps :: 0 items in queue, avg/max len 0/0



SEARCH COMPLETE!



----|------|----------------------------------------------------------------|-----------|-----------
 #  |  len |  music       4-bell runs      5678s     8765s     6578s    87s | avg score | calling
0 compositions generated in 43.57ms
❯
❯ monument_cli jadds-method.toml
INFO  [monument_cli::music] Using default music.  If you want no music, set `base_music = "none"`.
INFO  [monument::search::best_first] Limiting memory usage to 116.39MB
 #  |  len |  music       4-bell runs      5678s     8765s     6578s    87s | avg score | calling
----|------|----------------------------------------------------------------|-----------|-----------
  1 | 1312 |  140.00 :   73 ( 42f  31b)    4f  8b    4f  8b    0f  7b     0 |  0.091463 | sHHBsMHsHMWsMH
  2 | 1312 |  138.00 :   71 ( 36f  35b)    4f  8b    4f  8b    0f  7b     0 |  0.089939 | sHHsHBHsHMsMWM
  3 | 1344 |  144.00 :   75 ( 38f  37b)    4f  8b    4f  8b    0f  6b     0 |  0.093006 | sHBMsMHBHBHH
  4 | 1312 |  145.00 :   77 ( 40f  37b)    4f  8b    4f  8b    0f  8b     0 |  0.091768 | sHBMsMHsHsWBsMBsHH
  5 | 1312 |  145.00 :   75 ( 42f  33b)    4f  6b    4f  6b    0f 10b     0 |  0.091768 | BsMMsMHsHsWBsMBsHH
  6 | 1314 |  144.00 :   76 ( 43f  33b)    4f  6b    4f  6b    0f  9b     0 |  0.091248 | BsMMsMHsHsWBMMsWW>
  7 | 1314 |  144.00 :   78 ( 41f  37b)    4f  8b    4f  8b    0f  7b     0 |  0.091248 | sHBMsMHsHsWBMMsWW>
  8 | 1312 |  142.00 :   73 ( 36f  37b)    4f 12b    4f 12b    0f  4b     0 |  0.090244 | sHHHBHsHsWBsMBHH
  9 | 1344 |  143.00 :   73 ( 36f  37b)    4f 10b    4f 10b    0f  4b     0 |  0.092262 | sHHBsMHBHBHH
... etc

[kneasle]

Ah, I think I know what's going on here. The core composing algorithm in Monument is built around storing a large number of partially finished compositions in a 'queue' and repeatedly exploring the best one from that pool. So, the more entries Monument can store in this queue at once, the more ideas it can keep track of and the better the results will be. Basically, more memory usage = better results.

However, using more memory than is available on the machine is very bad, as doing so will slow the whole system down and eventually the Monument process will be killed.

So, Monument by default will limit its memory usage to (iirc) 80% of the unused memory of the machine, measured at the point of startup. So, if the machine is already using all the available physical memory, Monument will set its limit to 80% of 0, which is 0 bytes. It will then immediately throw all of its ideas away and produce nothing, as you've seen. I suspect when it ran to completion, there just happened to be some memory available while Monument was starting.

Monument has a flag to set the memory limit manually and override this default. I believe the flag is -M (but you can check by running monument_cli --help), so you can do e.g. monument_cli -M 500M file.toml and this will always use 500 megabytes of memory, even if that isn't available. This should at least give some results.

Hopefully this helps. If it doesn't work, then something deeper is wrong and more investigation will be needed.

I thought I had set a lower bound to this limit to avoid this, so I'll check this too and add one if there isn't a check already.