The MemoryArea is one of the core additions of the RTSJ specification to Java. In designing and implementing this feature, several decisions have to be taken that will have an impact on the performances, memory efficiency and predictability of the MemoryArea. What I strongly believe is that there is no one single design and implementation that can fit well in all use cases, as I like to claim: one size does not fit all. This means that a better way of designing and implementing the RTSJ memory area is that on relying on Generative Programming techniques so to be able to easily generate several different variation of MemoryAreas. The different "products" of the generative process could provide different compromise between performance, memory consumption, and predictability.

jRate extends the GCJ compiler and runtime system in order to provide the needed RTSJ features to applications. It is implemented using C++ and Java. The initial jRate MemoryArea implementation was rather flexible and provided a way of configuring several parameters, but it did not exploit completely the generative power of C++ templates. Currently I am redesigning and reimplementing jRate's MemoryArea in order to make it generative and extremely customizable by using C++ static metaprogramming facilities.

The RTSJ defines the javax::realtime::MemoryArea class which is supposed to represent a memory area which can be entered by real-time threads, with the result of becoming their allocation context. The RTSJ defines several different types of memory areas, but by no means the specified memory areas are enough for all applications nor they have enough flexibility. For instance, how can we select different implementation for the LTMemory or VTMemory?

In order to give more flexibility to developers, jRate provides already a way of configuring the type of native memory area used to implement the various RTSJ specified MemoryAreas, but the current framework does not lend itself easily to customization, nor it is very generative. The new native memory area framework will be strongly based on C++ templates and C++ static metaprogramming features, so to make it possible to both generate and customize easily the memory area to be used in a given deployment scenario.

If we think of a memory area in abstract terms we can individuate different properties and relationships. In particular the following point are quite importnat in the design of the memory area:

• A MemoryArea has associated a region of memory, and one of the thing that has to be sorted out is, who provides the MemoryArea with it? Is the memory locked? Is it zeroed? How is the memory aligned?
• What is the allocation policy used by a the memory?
• Is the allocation thread safe?
• Are the objects allocated within the memory finalizable? If so, what does the finalizer do?
• Should the memory returned by the memory area be zeroed?
• What should be done after finalization?
• How is aligned the allocated memory?
• What type of object header does the allocator uses?
• What tipe of sub-type algorithm and data structure are used in order to determine the validity of reference across memory areas?

Now there will be a jrate::mem::MemoryArea peer which is the native implementation of the javax.realtime.MemoryArea and this will actually be a host class, in the sense that it will be generated using static meta-programming starting by a collection of policies. In the reminder of this document the core policies individuated and then described.

FILL ME IN

This policy controls the allocation algorithm to be used. Some possibilities are:

• Stack Allocator--Very efficient allocator that allocates memory in a stack-like manner.
• Free-List Allocator--This allocator would use free lists in order to manage allocation.
• Buddy Allocator--This allocator would use the buddy system.
• You-name-it Allocator--Any policy you might like implement.

The MemoryArea represents a host class that binds together policies in order to implement a native peer for the javax.realtime.MemoryArea.

The MemoryArea is characterized by the following:

• Buffer Provider: Provides the buffer used to perform allocation
• Synch Policy: Controls the concurrency
• Post Allocation Policy: What should be done after a chunk of memory has been allocated?
• Cleanup Policy: What should be done after a chunk of memory is freed?
• Alignment: What are the alignment requirement for the allocated buffers?
• SubTypeTestPolicy: Since the assignment between different memory areas has to be checked, and since we have proved in our LCTES paper that this can be restated as a type theory problem, we can store a type information in each memory to be able to check type compability between different memories. Since different sub-type test algorithm can be used, ranging from hierarchy traversal, to displays and hierarchical encoding, in order to make it possible to play with different algorithms