VM heap size is maximum memory an application can consume; it does *not* mean it's total memory footprint, just how much *data* it can allocate at the same time. Therefore, the more resource-intensive application, the more heap it *requires* to run; this effect is very visible with LWP's and launchers which operate on large amounts of uncompressed bitmaps. Additionally, JIT pretty much requires large VM heap as the basic idea behind just-in-time optimizer is to trade memory efficiency for operating speed. VM heap is also roughly the biggest chunk of per-app virtual memory space that kernel can't "fake", share between multiple apps, silently drop and reload when accessed or do any of the other memory management tricks that allow to squeeze multiple apps that would each require hundreds of megabytes of memory under naive (e.g. DOS-and win95-like) memory allocation schemes into a handful of MBs that are actually available. Since it cannot be made disappear from physical memory to make room for something else without corrupting app state, the more complex apps grow, the more often they have to be killed --or force closed in Android terminology.
