Fine-tuning the final executable application

In addition to the measure memory requirement of the application, a small table of possible heap sizes and corresponding worst-case allocation overheads is printed. The worst case allocation overhead is given in units of garbage-collection work that are needed to allocate one block of memory (typically 32 bytes). A unit of garbage-collection work can be performed in a platform dependent amount of time. On the PowerPC processor, a unit corresponds to the execution of about 160 machine instructions.

From the printed table, we can now chose the minimum heap size that corresponds to the desired worst-case execution time for the allocation of one block of memory. A heap size of 388k corresponds to a worst-case of 20 units of garbage-collection work (3200 machine instructions on the PowerPC) per allocation of one block, while a smaller heap size of, e.g., 334k can only guarantee a worst-case of 40 units of garbage-collection (6400 PowerPC- instructions) work per allocation.

If we find that for our application 14 units of garbage-collection work per allocation is sufficient to satisfy all realtime requirements, we can build the final application using a heap of 443k:

  > jamaica -heapSize=443k -smart HelloWorld
      
Jamaica Builder Tool 2.2 Release 1
Generating code for target 'linux-gnu-i686'
 + HelloWorld__.c
 * C compiling
 * linking
 * stripping
Class file compaction gain: 95.85755% (1722798 ==> 71366)
    
  

The resulting application now runs with the minimal amount of memory that guarantees the selected worst-case execution time for memory allocation. The actual amount of garbage collection work that is performed is determined dynamically depending on the current state of the application (its memory usage etc.) and will in most cases be significantly lower than the described worst-case behaviour, so that in average an allocation is significantly cheaper than the worst-case allocation cost.