Memory Management

From Suhrid.net Wiki
Revision as of 08:17, 20 December 2011 by Suhridk (talk | contribs) (→‎Heap Memory)
Jump to navigationJump to search

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.
  • Assuming a time critical thread is using heap memory, Running garbage collection can have an impact on its response time. (Since the GC Thread cannot be preempted by the RT Thread)
  • Therefore, tt is necessary to provide memory that is not subject to GC.
  • The RTSJ provides two alternatives to traditional Java heap memory:
    • Immortal Memory
    • Scoped Memory
  • Immortal and Scoped memory areas exist outside the heap and are NOT subject to GC.
  • 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.
  • Immortal memory is shared among all threads.
  • 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).

MemoryParameters

  • Can be supplied when creating SO's. They can specify the max amount of memory a SO can consume in the memory area, the maximum immortal area and the rate of allocation.
  • When a SO exceeds its allocation or allocation rate limit, the error is handled as if the allocation failed because of insufficient memory.