Memory consumption has gone up

[chrisseaton]

$ ./build/bin/ruby --mmtk-plan=NoGC --mmtk-max-heap=1024000 -e 'p GC.stat(:mmtk_total_bytes)'

Used to be plenty to run this simple program - no longer is, and the process now seems to just hang.

[qinsoon]

Could be related with mmtk/mmtk-core#689. But that should only affect mark sweep.

[wks]

Yes. That's the cause.

PR #689 changed the way MMTk core accounts memory usage when using the malloc-based MarkSweep plan. Now if malloc allocates memory in any page, MMTk will count the whole page as "used". Therefore, MMTk will think the memory usage is going up, but the program is actually using as much memory as it used to.

With the current master of mmtk-core, the following command, when executed, attempts GC several time during start-up, and crashes due to out-of-memory error.

./miniruby --mmtk-plan=MarkSweep --mmtk-max-heap=1MiB -e 'p GC.stat(:mmtk_total_bytes)'

When I reverted that commit in mmtk-core (git revert 83fa8ec95a220be22fb38d5b6b3b3030a9f47f0c) and compile again, the same command runs without problem (prints "1048576" which is the heap size).

I suggest simply increase the (nominated) heap size. It has always been occupying more than 1MiB of spaces anyway.

[steveblackburn]

Just to be clear, accounting for memory at a page granularity is correct, accounting per object is not sound, and its introduction was a bug (ie mmtk/mmtk-core#689 was a bug fix).

This is because our underlying resources are pages. If we have two 8-byte objects each on a separate page, we have consumed two underlying pages. Saying that we consumed 16-bytes is unhelpful and misleading. As Yi said, only the mark-sweep collector was affected by the bug.