JamaicaVM -- User Documentation: The Virtual Machine for Real-time and Embedded Systems | ||
---|---|---|
Prev | Chapter 8. Realtime Specification for Java | Next |
Since JamaicaVM uses a realtime garbage collector, it does not need to impose the limitation that the Real-Time Specification for Java puts onto realtime programming onto realtime applications developed for JamaicaVM. The limitations that are relaxed in JamaicaVM affect the use of memory areas, thread priorities, runtime checks and static initializers.
For the development of applications that do not make use of these relaxations, the builder option -strictRTSJ (see below) can be set to dispable these relaxtations.
Since JamaicaVM's realtime garbage collector does not interrupt any application threads, it is not required for RealtimeThreads or even NoHeapRealtimeThreads to run in their own memory area that is not under the control of the garbage collector. Instead, any thread can use and access the normal garbage collected heap.
Nevertheless, any thread can make use of the new memory areas such as LTMemory or ImmortalMemory if the application developer wishes to do so. Since these memory classes are not controlled by the garbage collector, allocations do not require garbage collector activity and may be faster or more predictable than allocations on the normal heap. However, severe care is required in these memory areas to avoid memory leaks, since temporary objects allocated in scoped or immortal memory will not be reclaimed automatically.
In JamaicaVM, RealtimeThreads, NoHeapRealtimeThreads and normal Thread objects all share the same priority range. This means that the lowest possible thread priority for all of these threads is java.lang.Thread.MIN_PRIORITY and the highest possible priority is javax.realtime.PriorityScheduler.instance().getMaxPriority().
Since even NoHeapRealtimeThreads will not be interrupted by garbage collector activities, JamaicaVM does not require these threads not access objects allocated on the normal heap. Runtime checks that typically ensure that these threads do not access objects allocated on the heap are not performed by JamaicaVM.
To permit the initialization of classes even if their first reference is performed within ScopedMemory or ImmortalMemory within a RealtimeThread or NoHeapRealtimeThread, and to permit the access of static fields such as System.out from within these threads, static initializers are typically executed within ImmortalMemory that is accessible by all threads. However, this prevents these objects from being reclaimed when they are not used any longer and it provides a serious memory leak if dynamic class loading is used since memory allocated by the static intializers of dynamically loaded classes will never be reclaimed.
Since JamaicaVM does not limit acces to heap objects within any threads, there is no need to execute static initializers within ImmortalMemory. However, objects allocated in static initializers typically must be accessible by all threads, so they cannot be allocated in a scoped memory area if this happens to be the current thread's allocation environment when the static initializer is executed.
JamaicaVM therefore executes all static initializers within heap memory. Objects allocated by static initializers may be accessed by all threads, and they may be reclaimed by the garbage collector. There is no memory leak if classes are loaded dynamically by a user class loader.