First you need to understand the basics of virtual memory. You don't need to understand how a MMU works, but you do need to understand what a virtual address space is, and when you're dealing with virtual addresses or physical addresses. Otherwise you won't be able to make any sense of what you see.
Under Linux, you can access the system's physical memory via
/dev/mem: byte N of
/dev/mem is byte N in RAM or in memory-mapped peripherals. Unless you already know what you're looking for and where to look it for, you'll have a hard time finding interesting things there. The file
/proc/iomem describes what is mapped in the physical address space (RAM and peripherals).
You can access the kernel's virtual memory via
/dev/kmem: that gives you access to kernel code and data structures, and to devices that are currently mapped in the kernel, but not to process memory. Linux also has
/proc/kcore, which is similar to
/dev/kmem but puts an ELF header at the beginning, to facilitate running a debugger on the kernel. A debugger can open
/proc/kcore and work on it much like it would work on a process's memory. You can debug a running kernel by running
gdb /path/to/vmlinux /proc/kcore (there are more convenient facilities, in particular for remote debugging).
You can access a process's virtual memory via
/proc/$PID/mem. The file
/proc/$PID/maps summarizes what is mapped in the process's address space;
/proc/$PID/smaps goes into more detail.
There is no such thing as a “system heap” or a “centralized heap manager”. The closest thing is the whole system memory and the memory manager (all ~100kLoC of it in Linux, not including architecture-specific parts).