The Prizm OS has at least one heap, with a size of about 128 KB, located in the address range 0x881E0000 to 0x881FFFFF.
The implementation appears to have some bugs; namely, one can't allocate one big buffer at the first try, and it appears to not manage free blocks properly, making fragmentation go too high at a certain point and basically making the heap useless. If the heap is used heavily, it may also get to a point (usually after freeing many buffers) where the OS reports there's more heap available than the total heap size - and usually the values are quite out of range, like 10 MB. There is some more discussion on this forum thread.
The heap has the usual set of related syscalls.
The stack can provide a bigger continuous RAM area than the heap (up to about 500 KiB, depending on static RAM requirements, versus about 128 KiB). This, plus the limitations described above, means that to get the most out of the memory available to add-ins, one has to use non-standard ("incorrect") practices such as preferably using the stack instead of the heap.