Difference between revisions of "Memory Management"

From Suhrid.net Wiki
Jump to navigationJump to search
Line 4: Line 4:
 
* It is necessary to control how this memory is allocated so that it can be used effectively.
 
* It is necessary to control how this memory is allocated so that it can be used effectively.
 
* By doing this the program can increase its performance and predictability.
 
* By doing this the program can increase its performance and predictability.
 
 
 
* Running garbage collection can have an impact on the response time of a time critical thread.
 
* Running garbage collection can have an impact on the response time of a time critical thread.
 
* It is necessary to have memory that is not subject to GC.
 
* It is necessary to have memory that is not subject to GC.

Revision as of 11:27, 19 December 2011

Intro

  • Many real time systems have constraints on amount of memory available. e.g. because of cost or size constraints.
  • It is necessary to control how this memory is allocated so that it can be used effectively.
  • By doing this the program can increase its performance and predictability.
  • Running garbage collection can have an impact on the response time of a time critical thread.
  • It is necessary to have memory that is not subject to GC.
  • Provides two alternatives to traditional Java heap memory:
    • Immortal Memory
    • Scoped Memory
  • Both types of area are represented by the abstract javax.realtime.MemoryArea class.
  • Only javax.realtime.Schedulable objects are allowed to enter into a MemoryArea. If standard Java threads attempt to get in then an IllegalThreadStateException is thrown.
  • Schedulable objects must explicitly indicate the MemoryArea to allocate objects from, otherwise the standard Java heap will be used.
  • When a memory area is entered by a SO, all object allocation is performed from within that memory area.

Heap Memory

  • Standard Java Heap. Realtime Threads are allowed to use heap memory. Of course, reclamation of this memory is subject to when the JVM runs GC.

Immortal Memory

  • The memory associated with objects allocated in immortal memory is never GC'ed and never released during the lifetime of the application.
  • The programmer can reuse the memory by other means. e.g. by maintaining a pool of reusable objects.
  • Class objects and their associated static memories, along with objects created by static initialisation and interned strings (the list of program-defined constant strings that is maintained by the String class) are ALWAYS allocated in immortal memory. This is important, so if an object's static reference is assigned to an object created on scoped memory it will fail, because immortal to scope assignment is not allowed !

Scoped Memory

  • Scoped memory is a memory area where objects with a well-defined lifetime can be allocated.
  • Two types:
    • LTMemory : the allocation time for objects is directly proportional to the size of the object being allocated ,
    • VTMemory : allocation can occur in a variable time.
  • The expectation is that allocation time for objects in VTMemory will be faster but less predictable than allocation in LTMemory.
  • Each scoped memory object has a reference count which indicates the number of times the scope has been entered. Note it doesnt refer to the normal idea of Java GC reference counting.
  • When that reference count goes from 1 to 0, the memory allocated in the scoped memory area can be reclaimed (after running any finalization code associated with the allocated objects).