Enhancing the region model of RTSJ

401 views

Published on

AGCMemory

  • Be the first to comment

  • Be the first to like this

Enhancing the region model of RTSJ

  1. 1. Enhancing the region model of real-time Java for large-scale systems Pablo Basanta-Val Marisol García-Valls Iria Estévez-Ayres Universidad Carlos III de Madrid Telematics Engineering Department
  2. 2. OutlineIntroductionRecycling Floating Garbage with AGCMemoryExtending RTSJ HierarchySupporting AGCMemoryConclusions and future work 2/25
  3. 3. Introduction (I)Good properties of Java make it suitable for large-scalesystems: Portability Automatic memory management (garbage collector) Simplicity Networking support…When we introduce real-time constraints  problems withautomatic memory management Garbage collector introduces unpredictable breaks in program execution  deadlines may be missed 3/25
  4. 4. Introduction (II)Possible solutions: Real-time garbage collector techniques Regions (e.g in RTSJ Scope Memory)Neither is perfect Real-time garbage collectors maintain the Java programming style but they are not easy to tune Regions provide predictability but they modify the programming style 4/25
  5. 5. Introduction (and III)Our approach is a new type of region for RTSJ: AGCMemoryIt tries to improve the portability of regions while keepingsome of the advantages of GC-techniques It maintains the Java programming style It provides the predictability of regionsIt reduces the number of manual changes More portable applications It enhances the reuse of code and it decreases the development time 5/25
  6. 6. Recycling Floating Garbage with AGCMemoryFloating garbageUsing nested scopes to eliminate floating garbageUsing AGCMemory to eliminate floating garbage
  7. 7. Motivation: PeriodicCounter1. import javax.realtime.*2. public class PeriodicCounter extends RealtimeThread{3. public PeriodicConter(){4. super( null,//Schedulling par5. new PeriodicParameters(null,6. new RelativeTime(1000,0), //T7. new RelativeTime(50,0), //C8. new RelativeTime(100,0), //D9. null,null /*Handlers*/);10. null, //Memory parameters11. new LTMemory(100,100), //Mem. param12. null);13. start(); //starts thread.14. }15. int counter=1;16. public void run(){17. do{18. System.out.println(counter); // Allocates 88 bytes in RTSJ-RI19. counter++20. }while(waitForNextPeriod());21. }22. public static void main(String s[]){23. new HelloPeriodicCounter();24. } 7/25
  8. 8. Motivation (II) 250 free bytes 11. new LTMemory(300,300) 162 free 18. System.out.println(counter) bytes 74 free 18. System.out .println(counter) bytes -8 free 18. System.out .println(counter) bytes OutOfMemory Exception./RTSJ-RI PeriodicCounter123Mem-registry.c::InvokeNewInstance()- Went out of memory 8/25
  9. 9. Solving the problem with nested scopes1. import javax.realtime.*2. public class PeriodicCounter extends RealtimeThread{3. public PeriodicCounter(){4. //UnChanged}5.6. int counter=1;7. public void run(){8. LTMemory lt=new LTMemory(150,150); //Nested scope9. Runnable impr=new Runnable(){10. public void run(){11. System.out.println(counter);};12.13. do{ lt.enter(impr); counter++;14. }while(waitForNextPeriod());15. }16. public static void main(String s[]){17. new HelloPeriodicCounter();18. }19. } 9/25
  10. 10. Solving the problem with nested scopes (II) 250 bytes memoria libre new LTMemory(300,300) 220 bytes 9. lt=new LT(150,150) 150 b. impr 10. 10. Runnable impr libres 13. lt.enter(impr); 150 bytes //Using nested scope libres 62 bytes //Executes impr.run libres 150 bytes //Release nested scope libres 150 b. impr 220 bytes 13. counter++; libres 10/25
  11. 11. Nested Scopes ProblemsThe programmer has to set up: Number of auxiliary scopes Maximum size of each auxiliary scopeOther problems: Low portability High dependency on available classes Not especially intuitive (runnable objects) Runnable classes requiredOur solution: AGCMemory 11/25
  12. 12. AGCMemory1. import javax.realtime.*2. public class PeriodicCounter extends RealtimeThread{3. public PeriodicConter(){4. super( null,//Schedulling par5. new PeriodicParameters(null,6. new RelativeTime(1000,0), //T7. new RelativeTime(50,0), //C8. new RelativeTime(100,0), //D9. null,null /*Handlers*/);10. null, //Memory parameters11. new AGCMemory(250,250), //Mem. param12. null);13. start(); //starts thread.14. }15. int counter=1;16. public void run(){17. do{18. System.out.println(counter); counter++19. }while(waitForNextPeriod());20. }21. public static void main(String s[]){22. new HelloPeriodicCounter();23. }24. } 12/25
  13. 13. Using AGCMemory250 free bytes 11. new AGCMemory(300,300) 18. System.out.println(counter)250 free bytes //preinvocation162 free bytes //printing the counter250 free bytes //memory releasing250 free bytes 18. counter++ 13/25
  14. 14. Extending RTSJ Hierarchy
  15. 15. AGCMemory in the RTSJ class Hierarchy ImmortalMemory Memory Area HeapMemory ImmortalPhysicalMemory Scoped Memory VTMemory LTMemory AGCMemory LTPhysicalMemory VTPhysicalMemory 15/25
  16. 16. LTMemory VTMemory AGCMemory comparison LTMemory VTMemory AGCMemory Allocation time Linear Not bounded LinearDe-allocation after enter Yes Yes Yes method Partial de-allocation Not Yes Yes supported (when objects are (after method allocated) invocation) Predictable partial de- A priori, not Yes allocation bounded Shared Yes Yes No 16/25
  17. 17. Supporting AGCMemory Structures Runtime barriers Example revisited
  18. 18. AGCMemory Internal Structures0xAC00 method_ptr scape_ptr top top-1 . top-2 free_mem_ptr . . 0 agc_stack0x0C00 physical memoryChunk of physical memory: Objects are allocated in ascending memory addresses free_mem_ptr: position where the next object will be allocatedAGCstack (used in memory management algorithm) scape_ptr: decides whether the objects created during the invocation of a method maybe recycled or not. method_ptr: stores information about the set of objects created during the invocation of a method 18/25
  19. 19. Runtime BarriersBarrier Pseudo-code Functionality pre_invocation Agc.stack.push(memPtr, memPtr) It identifies the objects top→scape_ptr = free_mem_ptr; that will be created in the(before executing a invocation of a method method) top→method_ptr = free_mem_ptr;post_invocation If(top→scape_ptr ≥ top→method_ptr ) It destroys floating Free objects [top→method_ptr, free_prtr] objects or propagates (after executing a their destruction else (top_1→scape_ptr=top→scape_ptr) method) Agc.stack.pop() Intra_asig. Attrib=ref It detects whether the if (memArea(attrib)==memArea(ref)) objects of a method may(before executing an be destroyed when the && (memArea(attrib) instance of AGCMemory) assigment) methods ends && (ref≥attrib) top→scape_ptr=min{top→scape_ptr, attrib} 19/25
  20. 20. Example revisited (I) free_mem_ptr (0)method_ptr 0 0 250 free bytesscape_ptr agc_stack top Pre-invocation barrier (executed before System.out.println()) Agc.stack.push(memPtr, memPtr) top→scape_ptr = free_mem_ptr; top→method_ptr = free_mem_ptr; 20/25
  21. 21. Example revisited (II) free_mem_ptr (88)method_ptr 0 162 free bytes 0scape_ptr agc_stack top Object creation inside method System.out.println 21/25
  22. 22. Example revisited (and III) free_mem_ptr (0) 0 250 free bytes 0 agc_stack topPost-invocation barrier (executed after System.out.println())If(top→scape_ptr ≥ top→method_ptr )Free objects [top→method_ptr, free_prtr]Agc.stack.pop() 22/25
  23. 23. ConclusionsExisting types of regions hard to use Floating garbage problemAGCMemory: It reduces floating garbage problem It improves the automatic memory management Easier to use than nested scopes It uses constant time barriers 23/25
  24. 24. Future workImplementation of AGCMemory in a RTSJ open sourcevirtual machine We are using JRateEvaluation of the following trade-offs: Influence of the assignment AGCMemory barrier in the performance of applications Analysis of required memory for different types of applications 24/25
  25. 25. Enhancing the region model of real-time Java for large-scale systems Thanks 25/25

×