VM heap size doesnt change??

[jerroedr]

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.

So, i dont speak computer fluently, and while that kindof makes sense... is there a condensed/slightly more simplified version? lol

[captdroid]

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.

So, i dont speak computer fluently, and while that kindof makes sense... is there a condensed/slightly more simplified version? lol

Yes, a few posts back I posted a thread link to a app that has info in it that is simplified. Download and install that app. Or click this link: http://www.appbrain.com/app/vm-heap-...2k6.vmheaptool for a description and pictures. Click the first picture in the vm heap tool description for simplified info about vm heap size.