Problems in using System Heap
Posted: 24 January 2008, 7:24 AM
No comments on this? I thought it was rather cool.
I did find a couple of potential problems than need further investigation:
The second item may highlight a problem with the both the documentation and the heap allocation implementation. Although I don't believe this is documented, my analysis leads me to believe that each allocated block of memory requires a two byte pointer. This means that 1700 tasks need 3400 bytes for heap pointers. This extra 3400 bytes is equivalent to 3400/36 = 94 tasks. I think this explains why the real limit is 1703 tasks and not 1797. There is a check in the code for a 0 return from System.Alloc but the error message is not printed and the device just seems to hang after the 1703rd task has been created. I haven't had an opportunity to try this yet but this can be proven by using a single large memory allocation block and then using a sub-block of 35 bytes at a time for each task.
I did find a couple of potential problems than need further investigation:
- A period is printed for each task when it is created. There is a noticeable slowdown at around 1300/1400 tasks and then it speeds up again. I don't have the performance hooks yet to measure the time to create tasks, but they are easy enough to add.
- The maximum number of tasks I was able to get running is just over 1700. However this doesn't quite match up with the amount of available memory on the device. For a ZX128e, the first 768 bytes are unavailable, and the main task needs a stack of 49 bytes. Each task needs 1 byte for the counter and 35 bytes for its task header and stack. That means for 64K of RAM the theoretical maximum number of tasks is (64 * 1024 - 768 - 49)/(35 + 1), which equals 1797 tasks for a ZX128e.
The second item may highlight a problem with the both the documentation and the heap allocation implementation. Although I don't believe this is documented, my analysis leads me to believe that each allocated block of memory requires a two byte pointer. This means that 1700 tasks need 3400 bytes for heap pointers. This extra 3400 bytes is equivalent to 3400/36 = 94 tasks. I think this explains why the real limit is 1703 tasks and not 1797. There is a check in the code for a 0 return from System.Alloc but the error message is not printed and the device just seems to hang after the 1703rd task has been created. I haven't had an opportunity to try this yet but this can be proven by using a single large memory allocation block and then using a sub-block of 35 bytes at a time for each task.