We want to be able to support many applets at the same time. Today, applications have to define the heap up front and each applet reserves unused memory. A suggested solution for this problem is dynamically sized heap. Description: A real pain currently is that applications have to define the heap up front. Typically this means that after an app first hits OOM, it will then request way more heap than it actually needs, just to avoid another OOM. But this will often lead to long GM pauses as the heap is now 512m large and has to be crawled when it runs out of room. Also, having to specify the heap is a hit-or-miss thing. For applications that deal with lots of images, it can run out of heap very quickly. Also, if we are starting each Applet in its own VM (for robustness), then we will use system memory very quickly (even though an Applet may only need 10m heap, it will have by default 64mb or whatnot. If 10 such applets are running, then we're wasting 500m of system memory, and that won't look good for Java). Having some max like 512MB by default which can be extended via a system property is still a good idea, thus preventing a run-away program from eating all system memory.