A Java Virtual Machine for Hard Real-time Systems. Jan Vitek

Full text

(1)A Java Virtual Machine for Hard Real-time Systems Jan Vitek.

(2) Real-time Embedded Systems • strict functional and non-functional requirements ‣ ‣ ‣. Vast majority of microprocessors embedded Must be reliable, especially if mission- or safety-critical Must operate with limited resources, e.g. power, cpu, memory, price. • Traditional embedded system development ‣. low-level languages (e.g. ASM, C). low rate of reuse. • This model is not sustainable. due to scale of modern embedded systems 300,000 lines of code for ScanEagle UAV 5,000,000 Loc for DD(X) destroyer ... Moore’s law reflected in software.

(3) Real-time Embedded Systems. • The Real-time Java Challenge: ‣ ‣. Java is memory safe, simpler, and portable Large pool of Java programmers (but can they do RT?). ‣ Many tools, IDEs and libraries. ‣. but can we deliver competitive performance & meet non-functional requirements?.

(4) Plan. • The Open Virtual Machine Framework • Real-time Java Requirements and Semantics • Implementing RT Java • A Case Study in Avionics • Open Issues.

(5) An Open Virtual Machine Framework.

(6) Purdue’s Ovm • Ovm is a configurable virtual machine framework ‣ ‣ ‣ ‣. developed at Purdue, released under an Open Source licence entirely written in Java (~150Kloc) ported to x86, PPC, ARM minimal OS dependencies. • Implementation of Real-time Java on top of Ovm • An open source RTSJVM outperforms some commercial VMs. Baker, Cunei, Flack, Pizlo, Prochazka, Vitek, Armbuster+. A Real-time Java Virtual Machine for Avionics. RTAS06.

(7) A Configurable VM • A framework used to generate virtual machines from specifications ‣. multiple schedulers standard Java, priority preemptive. ‣. multiple execution engines & compilers ahead-of-time, just-in-time, interpreter. ‣. memory managers 8 different garbage collectors. ‣ ‣ ‣. Schedulers plain/ priority premptive. threading implementations object models .... Object Model .... User Code .... Locking thin/fat/ priority inherit. Software transactions on/off. Interpreter Ovm Executable image. OVM Configuration Static analysis None/CHA/RTA. Threading java/realtime. Memory Manager simple semi-space/ mostly copying/ RTSJ scope memory/ realtime GC. IO subsystems blocking/async. Palacz, Baker, Flack, Grothoff, Yamauchi, Vitek. Engineering an intermediate representation for Ovm. SCP05. JDK Libraries. Bootstrap Hotspot hosted. JIT (simplejit). AOT (j2c). GCC.

(8) Java in Java • Ovm written in Java ‣ ‣. Fewer software defects / faster development times Whole-system compilation inlines VM code into user code. • Approach: ‣ ‣ ‣. Retain Java syntax but extend semantics to express unsafe operations Idioms automatically recognized and translated to native code Surprisingly few places where needed, most of VM type safe. Flack, Hosking, Vitek. Idiom recognition in Ovm. Technical Report 2003.

(9) Java in Java (1) • Consider the implementation of moving garbage collector in Java. (Java code). Oop updateReference(MovingGC oop) {. int sz = oop.getBlueprint().getSize(oop);. . VM_Address loc = getHeapMem(sz);. . Mem.the().cpy(loc,oop,sz);. . oop.markAsForwarded(loc);. . return loc.asOop();.

(10) Java in Java (2) updateReference(Updater*this,MovingGC*oop){ sz = ...((*(*oop))->IfcTbl->v[23])(*oop,oop); loc = getHeapMem(this,sz); Mem_cpy(roots->v[37]),loc,oop,sz); return *(oop + 8) = loc;. • The bytecode of the VM rewritten at build time ‣ ‣. With the j2c engine, the following C++ is generate most OO operations disappear (eg.7 Java methods. one C++ indirect call).

(11) Idioms (3) • Going further in the representation of objects used in a moving GC: interface MovingGC extends Oop.WithUpdate { void markAsForwarded(VM_Address a)throws PragmaModelOp; boolean isForwarded()throws PragmaModelOp; VM_Address getForwardAddress()throws PragmaModelOp; }. • Ovm uses idioms to express low-level operations in Java ‣ ‣ ‣. MovingGC is a representation of pointers to objects with moving gc attributes GC code is insulated from the implementation of these operations Java exceptions are used as annotations (this is pre Java 5.0 metadata).

(12) Idioms (4) interface WithUpdate extends Oop { void updateBlueprint(Blueprint v) throws PragmaModelOp; void updateReference(int k, Oop v) throws PragmaModelOp; interface Oop { Blueprint getBlueprint() throws PragmaModelOp; VM_Address headerSkip() throws PragmaModelOp; Object asAnyObject() throws BCfiatcast. • Many kinds of object references in Ovm ‣. Oop is simplest, minimal support for getting blueprint, hash, and skip header. ‣. PragmaModelOp denotes an operations dependent on the Object Model selected at build time.

(13) Idioms (5) class VM_Address { VM_Address add(VM_Word i) throws BCiadd { ..hosted behavior.. } void setInt(int content) throws BCsetword {...}. r("setword", new byte[] {(byte)PUTFIELD_QUICK,0,0});. • Bare references are represented by the type VM_Address ‣. core operation have “hosted” behavior written in Java and a translation specified with a pragma (e.g. BCiadd). ‣. the translation is specified as a bytecode rewriting.

(14) Idioms (6) r("fiatcast", new PragmaTransformCallsiteIR.Rewriter() { boolean rewrite() { Instruction.CHECKCAST inst = followingCheckCast(); if ( null != inst ) { TypeName castType = inst.getResultTypeName(code,cp); cursor.addFiat(castType); int around = code.getPC() + inst.size(code); cursor.addGoto(cfe.getMarkerAtPC(around)); } else throw new PuntException("expected cast");. • More complex translations are implemented by Rewriters ‣. Eg: a fiatcast is an unchecked assertion inserted in the bytecode instead of a typecast. No operational behavior but needed to ensure that the bytecode well-typed.

(15) Idioms (7) class S3Model_B_M_F_H extends ObjectModel { Oop stamp( VM_Address a, Blueprint bp) { a.add(BP_OFFSET).setAddress(VM_Address.fromObject(bp)); a.add(HASH_OFFST).setInt(SEQ_HASH?nextHash++:a.asInt()); return super.stamp(a, bp); } String toCStruct() { return ("struct HEADER {\n"+ "\tstruct s3_core_domain_S3Blueprint*_blue.... • The Object Model determines the bit-level layout of objects ‣ ‣ ‣. size of header determined by the object model, initialization of header performed by the stamp() method mapping to C++ structs given by toCStruct (for AOT).

(16) Idioms (8) class S3Model_B_M_F_H extends ObjectModel { static void initMovingGC(char offset...) { rewrite("markAsForwarded:(Lovm/core/services/memory/” + "VM_Address;)V", new Rewriter() { boolean rewrite() { cursor.addQuickOpcode(PUTFIELD_QUICK, offset); ...}});. • The Object Model can define rewriters for any method marked as PragamModelOp. ‣. markAsForwarded overrides the field at a given offset in object header.

(17) the executive domain using Library Imports. The Ovm compiler recognizes UD classes that have the name LibraryImports. Any native methods in a library imports class are translated into calls to methods of the same name in the executive domain RuntimeExports object.. Virtual Machine Architecture User domain Java Application. Core Services Access. GNU CLASSPATH Library Glue Library Imports. Runtime Exports. Domain Reflection. Ovm Kernel. Executive domain CSA downcalls from Java bytecode CSA uses Ovm kernel methods to implement Java bytecode semantics Cross-domain calls.. Fig. 2. Overview of the Ovm architecture..

(18) Domain Isolation •. Kernel/User domain isolation necessary ‣ Single address space ‣ enforced by the type system ‣ requires java.lang.Object not built-in. •. Cross-domain interaction must be treated specially ‣ cross-domain references are opaque ‣ cross-domain access is reflective ‣ cross-domain exception require special handling.

(19) Performance 2. 2. 1.5 Ovm 1.01 HotSpot1.5.0.06 GCJ 4.0.2. 1.0. 0.5. ck ja. t tr. di au. m. o. c va ja. db. ss je. m. pe g. m. pr. es. s. 0.0. co. Time, relative to Ovm. 2.0. ‣ ‣. SpecJVM98, steady state, best of three runs, normalized wrt Ovm competitive with SUN Hotspot and better than GCJ. AMD Athlon XP1900+, 1.6GHz, 1GB RTLinux, 2.4.7-timesys-3.1.214 Ovm Java VM, AOT.

(20) Real-time Java.

(21) Five Requirements for RTJava 1. Real-time threads 2. Real-time Scheduling Policies 3. Priority inversion avoidance 4. Constant-time implementation 5. Bounded garbage collection. • We chose RTSJ standard as our API for real-time programming in Java [Bollela, Gosling, Brogsol, Dibble, Furr, Turnbull. The Real-Time Specification for Java. Addison-Wesley 2000].

(22) Realtime Threads • Realtime Thread can have execution eligibility higher than plain Java. threads, and are scheduled according to a set of release parameters. • RTSJ introduces: ‣ ‣. RealtimeThread extends Thread NoHeapRealtimeThread extends RealtimeThread “hard” real-time NHRTTs cannot access the heap NHRTTs can preempt GC.

(23) Scheduling • A Scheduler class ensures the timely or predictable execution of sequences of machine instructions. • A Scheduler manages scheduling/dispatching ‣ ‣ ‣ ‣. overruns may be monitored and handlers run missed deadlines must be monitored and handlers executed admission control may be performed multiple schedulers are supported. • Default scheduler is PriorityScheduler ‣ ‣ ‣ ‣. fixed-priority preemptive scheduling highest priority thread always run (FIFO within level) 28 RT priority queues (e.g. monitors) in priority order.

(24) Synchronization • Java synchronized. must support priority inversion avoidance. protocols ‣ Priority Inheritance (default). ‣. blocked thread priority is passed on to lock holder; queues maintained in priority order Priority Ceiling (optional) each lock has a priority ceiling threads are raised to the ceiling by default (how does one determine the ceiling?). • policies either system-wide or per-monitor • never used wait/notify ‣ ‣. unclear which thread needs a priority boost self blocking not amenable to schedulability analysis.

(25) Predictability • The implementation of a RTSJVM must provide worst case time bounds on operations. • The GC preemption latency needs to be specified • All basic object-oriented operations in constant time: ‣ ‣ ‣. method invocation subtype tests read/write barriers.

(26) Memory Management • Must support memory management that allows real-time code to exhibit deterministic behavior. • Options: ‣ ‣. real-time garbage collection side step the GC (but how? do we loose memory safety?). • Allocation time must be deterministic • A shared heap permits interference bw. real-time threads and plain threads. • RTSJ introduce a region-based memory management scheme with its Memory Area API.

(27) Scoped Memory Management IMMORTAL MEMORY AREA. • HeapMemory ‣ Objects garbage collected • ScopedMemory ‣ Object lifetime based. O1. O1. SCOPE A. on lexical scope. • ImmortalMemory ‣ Object lifetime unbounded. HEAP MEMORY AREA. O1. SCOPE B. O1. SCOPE C. O1.

(28) Memory Areas • Memory areas are used for all allocation • Different areas exhibit different properties relative to access and gc • Memory areas can be used to isolate actions of threads • void enter(Runnable logic). ‣. execute logic using this MemoryArea for allocation. • void executeInArea(Runnable logic). ‣ ‣. execute logic using this MemoryArea for allocation (temporary change) this area must be current scope or a parent scope. • void newInstance(Constructor c, ...). ‣. reflective allocation in a Memory Area.

(29) Memory Area Hierarchy • MemoryArea • HeapMemory • ImmortalMemory • ScopedMemory • VTMemory, ‣. LTMemory. variable/linear time allocation guarantees. • VTPhysicalMemory, ‣. map to specific physical addresses, e.g. for access to DMA, RAM.... • RawMemoryAccess, ‣. LTPhysicalMemory RawMemoryFloatAccess. a squence of bytes starting at a given address.

(30) Memory Hazards • ScopeCycleException ‣ ‣. attempt to enter a scope that has already been entered attempt to create a cycle spanning threads by creating more than one parent for a scope. • IllegalAssignmentError ‣. attempt to assign a reference pointing to a shorter-lived scope potentially creating a dangling pointer. • MemoryAccessError ‣. attempt to read a heap location from a NoHeapRealtimeThread potentially observing an object in midst of GC.

(31) Implementation.

(32) 12. Cross Domain Calls. ·. public ValueUnion call(Oop recv) { VM_Area area = MemoryManager.the().getCurrentArea(); Object r1 = MemoryPolicy.the().enterScratchPadArea(); try { InvocationMessage msg = makeMessage(); VM_Area r2 = MemoryManager.the().setCurrentArea(area); try { ReturnMessage ret = msg.invoke(recv); ret.rethrowWildcard(); return ret.getReturnValue(); } finally { MemoryManager.the().setCurrentArea(r2); } } finally { MemoryPolicy.the().leave(r1); } }. •. Fig. 10: ScratchReflective Pad. A scratch pad structures is a thread-local memory area with a clearly delimited lifetime. data aretemporary allocated in temporary memory The call() method the semantics of afor cross-domain call. It starts in the caller’s area, area, before areasimplements to circumvent need GC entering the scratch pad with enterScratchPadArea(). The message object is allocated there, then the scratchpad area is a value thread memory area Before returning, the allocation associated method‣isAinvoked and the return or local exception is retrieved. context is restored, setCurrentArea(), and scratch memory is reclaimed with leave().. 3.7 Scoped Memory and Region Based Memory Management.

(33) if ((ta.prange - sa.crange) & MASK) != RES) fail(); }. Scoped Memory Barriers. Fig. 12: RTSJ write barrier slow path. storeCheckSlow() fails, throwing an exception, if the assignment would violate RTSJ memory semantics. There are two failure cases: if we try to store a a reference to a scope allocated object into the heap or immortal, and if we try to store a reference to an object with shorter or disjoint lifetime. This method is never inlined.. void readBarrier(VM_Address src) throws PragmaInline, PragmaNoBarriers, PragmaNoPollcheck { if (!doLoadCheck) return; if (src.diff(heapBase).uLessThan(heapSize)) fail(); } Fig. 13: RTSJ read barrier. readBarrier() fails if the current thread is a NoHeapRealtimeThread and the target of the reference is a heap location. This code is inserted before every load of a reference field and is always inlined.. • Scoped Memory areas require R/W barriers on all reference. VM_Area areaOf(Oop mem) { accesses VM_Word off = VM_Address.fromObject(mem).diff(heapBase); from accessing a heap ‣ Read barriers are needed to prevent a NHRT Thread if (off.uLT(VM_Word.fromInt(heapSize))) return heapArea; (which may be inconsistent if a GC is progress) off = location VM_Address.fromObject(mem).diff(scopeBase); if (!off.uLT(VM_Word.fromInt(scopeSize))) immortalArea; that lifetime of the ‣ Write barriers prevent dangling pointers by checkingreturn int idx = off.asInt() target object’s scope is >>> longerblockShift; that of the object receiving the reference return scopeOwner[idx]; ‣ both types are constant time } Fig. 14: The areaOf() method returnsSubtype the memory an ECOOP03 object which can be either heap, immortal or Palacz, Vitek. tests inarea realof time. scoped. We keep a mapping from memory blocks to scoped memory instances, scopeOwner, to speed up discovery..

(34) ·. 13. Scoped Memory Barriers. void storeCheck(VM_Address src, int offset, VM_Address tgt) throws PragmaNoPollcheck, PragmaNoBarriers, PragmaInline { sb = src.asInt() >>> blockShift; void int storeCheck(VM_Address src, int offset, VM_Address tgt) int tb = tgt.asInt() >>> blockShift; throws PragmaNoPollcheck, PragmaNoBarriers, PragmaInline { if tb) storeCheckSlow(sb, tb); int(sb sb != = src.asInt() >>> blockShift; } int tb = tgt.asInt() >>> blockShift; ifwrite (sb != fast tb) Fig. 11: RTSJ barrier path.storeCheckSlow(sb, storeCheck() verifies if thetb); two objects are allocated in the same block. If not,}follow the slow path. The method is inserted before every write to a reference field and is always inlined. Fig. 11: RTSJstoreCheckSlow(int write barrier fast path. storeCheck() void sb, intverifies tb)if the two objects are allocated in the same block. If not, follow the slow path. The method is inserted before every write to a reference field and is always inlined.. throws PragmaNoPollcheck, PragmaNoBarriers, PargamNoInline { VM_Word tidx = VM_Word.fromInt(tb void storeCheckSlow(int sb, int tb) - scopeBaseIndex); if (!tidx.uLessThan(scopeBlocks)) return; throws PragmaNoPollcheck, PragmaNoBarriers, PargamNoInline { Area ta = scopeOwner[ tidx.asInt() -];scopeBaseIndex); VM_Word tidx = VM_Word.fromInt(tb VM_Word sidx = VM_Word.fromInt(sb -return; scopeBaseIndex); if (!tidx.uLessThan(scopeBlocks)) if (!sidx.uLessThan(scopeBlocks)) Area ta = scopeOwner[ tidx.asInt()fail(); ]; Area sa = scopeOwner[sidx.asInt()]; VM_Word sidx = VM_Word.fromInt(sb - scopeBaseIndex); if == ta) return; if (sa (!sidx.uLessThan(scopeBlocks)) fail(); if ((ta.prange - sa.crange) & MASK) != RES) fail(); Area sa = scopeOwner[sidx.asInt()]; } if (sa == ta) return; if write ((ta.prange - sa.crange) & MASK) != RES) fail(); Fig. 12: RTSJ barrier slow path. storeCheckSlow() fails, throwing an exception, if the assignment would } violate RTSJ memory semantics. There are two failure cases: if we try to store a a reference to a scope. allocated object into the heap or immortal, and if we try to store a reference to an object with shorter or disjoint Fig. 12: RTSJ write barrier slow path. storeCheckSlow() fails, throwing an exception, if the assignment lifetime. This method is never inlined. would violate RTSJ memory semantics. There are two failure cases: if we try to store a a reference to a scope allocated into the heap or immortal, and if we try to store a reference to an object with shorter or disjoint voidobject readBarrier(VM_Address src).

(35) void someMethod() { ... while(...) .... void someMethod() { POLLCHECK(); ... while(...) { ... POLLCHECK(); } } (aka “green threads”). { ⇒ Sync Threads, Scheduling, }. } cooperative scheduling • Compiler enforced. ‣ ‣ 8. Provides consistent semantics across RT OSes. Fig. 5: Compiler inserted cooperative multi-threading. In Ovm rescheduling can only occur at poll-c insertedon by uniprocessors the compiler in the(ie. bytecode. All code paths must eventually encounter a poll-chec Cheaptions atomicity most embedded systems) Bounding the number of instructions between is a key part in reducing preemption latency.. · • Preemption by low-overhead compiler-inserted polling. union { struct void someMethod() { { void someMethod() { volatile int16_t notSignaled; POLLCHECK(); volatile int16_t notEnabled; ... ... s; while(...) } { while(...) { volatile int32_t pollWord; ... ... } pollUnion; POLLCHECK();. ⇒. }. } }. }. POLLCHECK: if (pollUnion.pollWord == 0) { Fig. 5: Compiler inserted cooperative multi-threading. In Ovm rescheduling can only occur at poll-check instrucpollUnion.s.notSignaled = 1; tions inserted by the compiler in thepollUnion.s.notEnabled bytecode. All code paths must eventually = 1; encounter a poll-check instruction. Bounding the number of instructions between is a key part in reducing preemption latency. handleEvents(); }. union { struct {. Fig. 6: Definition of the 32-bit polling word and the compiler inserted code fragment implementin No synchronization is required as rescheduling can only occur when handleEvents() is execu.

(36) 4.4 Latency and Throughput Impact of Poll-checks.. Compiler inserted poll-checks are essential to Ovm’s scheduling inf the only points where a thread can be preempted. Polling has the a ing the implementation of synchronization primitives. The downsid overheads, both from the time spent executing the poll-check and mizations impeded by their presence, and (ii) potential increases i latency ofthepolling is low. • Throughput and Decreasing frequency of poll-checks means that there will be lo histos.nb benefits in terms of atomicity which have not been quantified ‣ There are some withpollcheck interrupts deferred.. Threads, Scheduling, Sync. 100 jack jack. 80. mtrt mtrt. Counts. mpegaudio mpegaudio javac javac db db jess jess. 60 40 20. compress compress -0.5%. 0.5%. 1.5%. 2.5%. 3.5%. 4.5% 0. 5. 10 15 20 25 Pollcheck Latency in Microseconds cent overhead of poll-checks in SpecJVM98 benchmarks. In this graph, 0% overhead indicates that ling did not slow down the benchmark. Overhead is under 3%. Fig. 28: Distribution of poll-check latencies for the PRiSMj 100X scenario. Pol Armbuster, et.al. A Real-time Java Virtual Machine with Applications in Avionics. To appear 2006. between an interrupt and a poll-check that services that interrupt. Worst case observe. Boeing PRiSMj. LOC. Classes. Data. Code. 108’004. 393. 22’944 KB. 11’396 KB. Fig. 28 gives the distribution of interrupt-to-check latencies for the.

(37) Threads, Scheduling, Sync • Cooperative multi-threading must deal with blocking IO calls ‣ ‣ 22. Ovm implements an Async I/O layer that emulates standard Java libraries four different I/O configurations are provided. · CLASSPATH Library POSIX I/O Emulator Ovm Async I/O Framework SIGIO. Select. Polling. Stalling. Operating System Fig. 21: Ovm I/O subsystem stack. An implementation of the POSIX I/O API based on AsyncIO is provided to prevent the entire virtual machine from blocking during file or network operations. There are four different implementations of AsyncIO with different characteristics..

(38) Boeing PRiSMj 108’004 393 22’944 KB 11’396 KB -0.5% 1.5% 2.5% 3.5% KB 4.5% UCI RT-Zen 0.5% 202’820 2447 26’847 12’331 KB GNU classpath 479’720 1974 – – Fig. 29: Percent overhead of framework poll-checks in SpecJVM98 In this graph, Ovm 219’889 benchmarks. 2618 – 0% overhead – indicates that enabling polling did notRTSJ slow libraries down the benchmark. Overhead 268 is under 3%. 28’140 – –. Static Analysis. LOC Classes Code Fig. 30: Footprint. Lines of code computed overall all JavaData sources files (w. comments). Data/Code Boeing PRiSMj 108’004 393 22’944 KB 11’396 KB and Zen) on a PPC. measure the executable Ovm image for two complete application (PRiSMj UCI RT-Zen GNU classpath classes used isOvm theframework number at runtime. The number RTSJ librariesof. 202’820 2447 26’847 KB 12’331 KB 479’720 1974 – – of 219’889 classes that2618 are determined to be live, – – i.e. may be accessed methods of live classes. The 28’140 defined 268is the sum –of all methods –. number of method used is the subset of those methods which may be invoked. Methods Fig. 30: Footprint. Lines of code computed overall all Java sources files (w. comments). Data/Code that are not used need not be compiled. measure the executable Ovm image for two complete application (PRiSMj and Zen) on a PPC. classes. methods. call. casts. classes used is the number of classes that are determined to be live, (% i.e.removed) may be accessed loaded / used defined / used sites (% devirt) at runtime. The number of methods defined is the sum of all methods of live classes. The RTZEN 3266 / 941 20608 / 9408 67514 (89.7%) 5519 (37.7%) number of PRiSMj method used3446 is the subset of those methods which may be invoked. Methods / 953 13473 / 6616 46564 (89.8%) 73408 (96.9%) that are not used need not be compiled. Fig. 31: Impact of compiler optimizations. classes methods loaded / used RTA, defined / used implements inlining. call sites (% devirt) and constant. casts (% removed)at propagation. the casts removal. • Ovm Finally, Fig. 31 measures the opportunities for devirtualization and type RTZEN 3266 20608 / 9408 67514 (89.7%) 5519 (37.7%) bytecode level/is941virtual In Java,PRiSMj every method by default, we show that in the two applications at hand 3446 / 953 13473 / 6616 46564 (89.8%) 73408 (96.9%) 90% of call sites can be devirtualized. Type casts (e.g. instance of) are frequent operaFig. is 31:able Impact compiler optimizations. tion in Java. The compiler to of determine that a large portion of them are superfluous and can be optimized away. Finally, Fig. 31 measures the opportunities for devirtualization and type casts removal..

(39) -10% -15% -15% -20% -20%. Accurate Garbage Collection 201 compress. 202 jess. 209 db. 213 javac. 222 mpegaudio. 227 mtrt. 228 jack. Geometric Mean. 201 compress. 202 jess. 209 db. 213 javac. 222 mpegaudio. 227 mtrt. 228 jack. Geometric Mean. • Ovm’s ahead-of-time compiler generates C++. Figure 13. Overhead of accurate collection, 256MB heap. Median of 60 runs, with Ovm and bytecode inlining. Results normalized with respect to the Ovm Conservative collector. Absolute numbers are in Fig. 26 in Appendix. gcc does not provide information about pointers on the C stack. 30%. ‣ ‣ ‣. use a mostly copying collector, but for RT must avoid pathological cases evaluate four techniques for accurate GC of C programs. Thunking Counter Thunking PtrStack Counter Henderson PtrStack. 30% 25% 25% 20%. Henderson. Percent Percent Overhead Overhead. 20% 15% 15% 10% 10% 5% 5% 0% 0% -5% -5% -10% -10% -15% -15% -20% -20%. 201 compress. 202 jess. 209 db. 213 javac. 222 mpegaudio. 227 mtrt. 228 jack. Geometric Mean. 201 compress. 202 jess. 209 db. 213 javac. 222 mpegaudio. 227 mtrt. 228 jack. Geometric Mean. Figure 14. Overhead of accurate collection, 32MB heap. Median of 60 runs, with Ovm and bytecode inlining. Results normalized with respect to the Ovm Conservative collector. Absolute numbers are in Fig. 28 in Appendix..

(40) max 15 5 0. 50. 100. 150. 200. 250. rtgc. 40. Real-time Garbage Collection 35. 30. 25. (a) Real-time GC with scope checks. rtgc. 20. 15. median 16 avg 15.4 max 42. 40 10. 35. pollcheck histos.nb. 50. 5 0. 50. 100. 150. 200. 250. 40. Time (millis). 30. Fig. 12. Performance Evaluation. Comparing the performance of the collision detection implemented with (a) RTSJ, (b) STARS and (c) Java with a real-time garbage collector. We measure the30 time needed to process one frame of input by a 10Hz high-priority thread. The x-axis shows input frames and the y-axis processing time in milliseconds. The RTGC spikes at 43ms when the GC kicks in. No deadlines are missed. The average per frame processing time of STARS is 28% less20 than that of RTSJ and RTGC. Variations in processing time are due to the nature of the algorithm. Counts. 25. 20. 15 10. 10 0.2. 5 0. 50. 100. 150. 200. 250. 0.4 0.6 0.8 GC Pause Time in Milliseconds.. Pause time (millis). 1. 1. Frames Printed by Mathematica for Students. • Ovm’s real-time garbage collector ‣. provides strong bounds on both pause time and utilization [Bacon+ A Real-time Garbage Collector with Low Overhead POPL03]. AMD Athlon XP1900+, 1.6GHz, 1GB RTLinux, 2.4.7-timesys-3.1.214 Ovm RTSJ VM, AOT, priority preemptive, PIP locks. Baker, Cunei, Pizlo, Vitek. Accurate Garbage Collection in Uncooperative Environments TechRep 2006.

(41) check. 40. Scoped Memory. 35. 30. 25. (a) RTSJ with scope checks. check. 20. 15. median 17 avg 15.4 max 21. 40 10. 35. IMMORTAL MEMORY AREA. HEAP MEMORY AREA. 5 0. 50. 100. 150. 200. 250. O1. nocheck. 30. O1. 40. Time (millis). SCOPE A 35. 25 30. O1. 20. (b) STARS no scope checks. 20. 15. SCOPE B. SCOPE C. 15. 10. median 12 avg 11.2 max 15. 10. O1. 5 0. 5 0. 50. 100. 150 rtgc. 50. 100. 40. Frames. 200. 250. 150. 200. 250. • Scoped Memory is an alternative to GC 35. 30. ‣ ‣. O1. 25. Object are allocated in regions - entire regions deallocated in O(1) (a) Real-time GC with scope checks Memory safety enforced by dynamic checks 25. 20. 15. median 16 avg 15.4 AMD Athlon XP1900+, 1.6GHz, 1GB RTLinux, 2.4.7-timesys-3.1.214 max 42 10. Ovm RTSJ VM, AOT, priority preemptive, PIP locks 5. 0. 50. 100. 150. 200. 250. Fig. 12. Performance Evaluation. Comparing the performance of the collision detection implemented with (a) RTSJ, (b) STARS and (c) Java with a real-time garbage collector. We measure the time needed to process one frame of input by a 10Hz high-priority thread. The x-axis shows input frames and the y-axis processing time in milliseconds. The RTGC spikes at 43ms when the GC.

(42) Case Study.

(43) Case Study ScanEagle UAV provides surveillance and reconnaissance data Mission Control Payload Card. Application Components. PRiSMj Flight Software:. ScanEagle Patform. Frame Controller. PeriodicParameters RelativeTime. Event Queues. NoHeapRealtimeThread. Event Channel. 953 Java classes, 6616 methods. Multiple Priority Processing: High (20Hz) - Communicate with Flight Controls Medium (5 Hz) - Computation of navigation data Low (1 Hz) - Performance Computation. AsyncEvent BoundAsyncEventHandle. Object Reference Broker Navigation Serial I/O Device PassThrough. Real-time JAVA Virtual Machine. ImmortalMemory. Flight Control Card. Threats, No Fly Zones Flight Data. Ground Station. Baker,Cunei,Flack,Pizlo,Prochazka,Vitek,Armbuster,Pla,Holmes. Real-time Java Virtual Machine for Avionics. RTAS06.

(44) Case Study 0.7. 0.6. Infrastructure. time in millis. 0.5. 0.4. 0.3. 20Hz 5Hz. 0.2. 0.1. 1Hz 0 1. 21. 41. 61. 81. 101 121 141 161 181 Frames 201 221 241 261 281 301 321 341 361 381. • Boeing PRiSMJ 100x synthetic workload ‣. Results faster than C++ version as reported in [Sharp+ RTSS03]. 300Mhz PPC, 256MB memory, Embedded Planet Linux Ovm RTSJ VM, AOT, priority preemptive, PIP locks.

(45) Lessons Learned • Case Study ‣ ‣ ‣. Java development straightforward C++ required testing on x86 & PPC. • Implementation ‣ ‣. Open-sourced a compliant RTSJ VM Good performance characteristics. • Impact ‣. R202? t H7. First successful RTSJ live flight test.. ScanEagle won a Duke’s choice Award at JavaOne.. •. compiler incompatibilities bugs - EN B2rv21 . B = 711:2w. r. S0. ? E. g:2 . ? C? = . ? ? 21 .. • PrAv7121 r2. :-t7= 2 0A= = grAC? 1 Bt. t7A?. • BCt 0A? 02r? r2= . 7? 21 . b.

(46) Conclusions.

(47) Where to next? Requirements for the next programming language for hard real-time systems. • real-time support ‣. sheduling, priority inversion, access to underlying hardware. • high-level software composition mechanisms ‣. inheritance and dynamic binding not sufficient. • statically analyzable ‣. eliminate features that make analysis impossible or unsound. • specifications ‣. support for specifying bounds on space and time (as well as correctness). • pluggable types ‣. ability to subset the language for safety critical domains.

(48) Acknowledgments The Ovm team Jason Baker, Antonio Cunei, Chapman Flack, Filip Pizlo, Marek Prochazka, Christian Grothoff, Krista Grothoff, Andrei Madan, Gergana Markova, Jeremy Manson, Krzysztof Palacz, Jaques Thomas, Jan Vitek, Hiroshi Yamauchi ✹ Purdue University ✹ DLTeCH ...... David Holmes. DARPA Program Composition for Embedded Systems NASA/NSF HDCP - Assured Software Composition for Real-Time Systems NSF Aspectual Configuration of Real-time Embedded Middleware The Boeing Company.

(49)

No results found