The Java Virtual Machine (JVM) on a Nokia Series 40 phone has access to a runtime heap memory space of 2 MB. On some models, such as the Nokia Asha 303 on Nokia Asha software platform, this is 4 MB. Design your application to flexibly take advantage of all the available memory, so it may run faster or more smoothly on these phones.
There are also native methods and native stacks for the underlying drivers.
Instances of classes are objects created in the heap. Arrays of objects and primitive types are also created on the heap.
JVM loaded methods of classes also consume heap space. Thus, the total number of methods in loaded classes has a direct impact on how much heap space is left for other data. These memory allocations are permanent for the runtime of the application and are not dynamically unloaded by the JVM once a class is no longer in use. This behavior of classes and methods is different from the objects you create in your application – they are automatically unloaded, or “garbage collected” when they are no longer referenced by your application.
Heap memory becomes crowded after some time as objects which are
no longer used continue to hang around. When more space is needed,
or when the developer explicitly calls System.gc(), then a “garbage collection” cycle will find those parts of heap
memory which are no longer referenced by the program and reclaim them
for future use.
One of the best techniques for increasing application performance
by using all the available heap memory but still avoiding OutOfMemoryError is to implement a WeakReference
Hashtable cache of all your large objects. This is discussed
in the section WeakReference Object Caching.