I’m helping someone with a project that is approaching memory limits for the Z-Machine (and it has to use Z-machine instead of Glulx). We’ve already activated memory economy, and it’s still managing to hit the overall memory limit – especially the readable memory limit.
The part that seems to be contributing the most to this is the addition of entries to a table with large text strings (up to 1800 characters). I can see that arrays are being added at the I6 level to represent the new rows, but these arrays don’t seem like they take up that much memory (maybe 30 bytes apiece). The strings are being parked in packed address memory as either constant strings or routines, and my understanding is that therefore the string sizes themselves shouldn’t affect the readable memory limit.
Cutting the table size down to the point where it will compile in the IDE shows almost 2K still available in readable memory, so it seems like it should be possible to add the requisite rows (about 12) without breaking the readable memory limit.
Right now, I’m looking at a constant generated by the I7 compiler called MEMORY_HEAP_SIZE
. The first problem seems to occur when this value, which is determined by the compiler somehow, is increased from 16384 to 32768. This causes a compilation fault because of the line:
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Flex.i6t: The Heap
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
Array Flex_Heap -> MEMORY_HEAP_SIZE + 16; ! Plus 16 to allow room for head-free-block
At 32768, adding 16 breaks the signed integer limit for the Z-Machine, but increasing it to this amount also adds 16K to the readable memory limit because that’s where the heap lives. [Side note: since negative values for an array index don’t make sense, shouldn’t the compiler be treating this as an unsigned value? EDIT: Upon further consideration, it wouldn’t matter in the Z-Machine’s case, anyway, since a word array of size 32768 can’t be crammed into the available writable memory on that VM due to the presence of even minimum competing items such as class object definitions, and compiler 6.35 won’t allow an array size value higher than 32767.]
Manually modifying the value of MEMORY_HEAP_SIZE
in the generated I6 code allows command line compilation of the generated I6 source, but it seems risky to do so. What is the basis by which the I7 compiler chooses the value for this constant?