First, note that there are at least two important measures of memory use: total memory size and working set size. I tend to oversimplify them slightly and think of them as "paging file use" and "RAM use", respectively. Total memory size is how many pages of virtual memory your program has been allocated. Working set size is how many pages of memory your program needs to have in RAM at once in order to run smoothly.

If your program uses more total memory than is available to it (either due to quota restrictions or just how much is available to the operating system minus how much the kernel and other processes are using), it will probably die [well, usually malloc() will fail, which will usually either cause a quick death or trigger bugs which cause a slightly slower but more colorful death; but some operating systems will let malloc() succeed but when you actually try to use the memory the OS will notice the problem and kill you (or some other process!)].

If your program needs a larger working set than is available, then it will start "paging" too much and slow down noticeably. The size of the working set has a lot to with how the memory is accessed. By making your data structures such that related items are close together in memory, you can often dramatically reduce your program's working set size. BTW, Perl plays this same trick by trying to arrange for its most-used C subroutines to be close together in memory (which is why we have the pp_hot.c file).

To get the working set size, you'll have to ask the operating system. To get the total memory size, I'd build a version of Perl with DEBUGGING_MSTATS defined and then use Devel::Peek::mstats (though the documentation for this has been moved or purged so you may have to dig for it or reverse engineer it).