As far as mine understanding of JVM goes it works with memory in quite a different way. When JVM starts up it allocates large chunk of memory up-front (usually

As far as mine understanding of JVM goes it works with memory in quite a different way. When JVM starts up it allocates large chunk of memory up-front (usually hundreds of megabytes) even though it doesn't really need all that memory. Usually only a part of that memory is actually used at any given moment. JVM will manage that memory with custom internal malloc/free which will allocate memory to Java objects. All this is needed to implement efficient garbage collection. See [1] for details. Such complicated memory management is really efficient and works great for server apps. On the client -- not so much. In that case I would rather prefer a slower GC that just uses malloc/free. Why? Because from end-user perspective that's not really great when a simple app grabs a 100-200mb of memory. If all apps were like this you wouldn't be able to run many of them at the same time. (Especially on the older hardware.) Moreover for a complex JVM apps 500mb+ of allocated RAM might be a requirement. [2] Great example of how things should work is .NET/Mono. Both of the .NET runtimes allocate memory only when it's actually needed and start-up performance is great too. All things considered JVM and CLR are very similar runtimes and there is no reason for a more client-oriented JVM implementation not to be possible. [1] http://www.quora.com/How-does-garbage-collection-work-in-the-JVM http://www.quora.com/How-does-garbage-collection-work-in-the... [2] Eclipse for instance recommends to configure jvm to allocate at least 500mb up-front. (This is done via -Xms and -Xmx parameters.)