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
Outline

Introduction

Recycling Floating Garbage with AGCMemory

Extending RTSJ Hierarchy

Supporting AGCMemory

Conclusions and future work




                                            2/25
Introduction (I)

Good properties of Java make it suitable for large-scale
systems:
   Portability
   Automatic memory management (garbage collector)
   Simplicity
   Networking support…


When we introduce real-time constraints  problems with
automatic memory management
   Garbage collector introduces unpredictable breaks in program
   execution  deadlines may be missed




                                                    3/25
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
Introduction (and III)

Our approach is a new type of region for RTSJ: AGCMemory

It tries to improve the portability of regions while keeping
some of the advantages of GC-techniques
   It maintains the Java programming style
   It provides the predictability of regions


It reduces the number of manual changes
   More portable applications
   It enhances the reuse of code and it decreases the development
   time




                                                    5/25
Recycling Floating Garbage with
         AGCMemory




Floating garbage
Using nested scopes to eliminate floating garbage
Using AGCMemory to eliminate floating garbage
Motivation: PeriodicCounter
1.    import javax.realtime.*
2.    public class PeriodicCounter extends RealtimeThread{
3.    public PeriodicConter(){
4.    super(      null,//Schedulling par
5.                new PeriodicParameters(null,
6.                        new RelativeTime(1000,0), //T
7.                        new RelativeTime(50,0),   //C
8.                        new RelativeTime(100,0), //D
9.                        null,null /*Handlers*/);
10.               null, //Memory parameters
11.               new LTMemory(100,100), //Mem. param
12.               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-RI
19.               counter++
20.        }while(waitForNextPeriod());
21.   }
22.   public static void main(String s[]){
23.       new HelloPeriodicCounter();
24.     }                                                  7/25
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 PeriodicCounter
1
2
3Mem-registry.c::InvokeNewInstance()- Went out of
   memory
                                                      8/25
Solving the problem with nested scopes

1.    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 scope
9.       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
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
Nested Scopes Problems

The programmer has to set up:
   Number of auxiliary scopes
   Maximum size of each auxiliary scope

Other problems:
   Low portability
       High dependency on available classes
   Not especially intuitive (runnable objects)
   Runnable classes required

Our solution: AGCMemory




                                                 11/25
AGCMemory
1.    import javax.realtime.*
2.    public class PeriodicCounter extends RealtimeThread{
3.    public PeriodicConter(){
4.    super(      null,//Schedulling par
5.                new PeriodicParameters(null,
6.                        new RelativeTime(1000,0), //T
7.                        new RelativeTime(50,0),    //C
8.                        new RelativeTime(100,0), //D
9.                        null,null /*Handlers*/);
10.               null, //Memory parameters
11.               new AGCMemory(250,250), //Mem. param
12.               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
Using AGCMemory



250 free bytes   11. new AGCMemory(300,300)

                 18. System.out.println(counter)

250 free bytes         //preinvocation


162 free bytes          //printing the counter



250 free bytes         //memory releasing


250 free bytes   18. counter++



                                            13/25
Extending RTSJ Hierarchy
AGCMemory in the RTSJ class Hierarchy


    ImmortalMemory          Memory Area

           HeapMemory                    ImmortalPhysicalMemory

              Scoped Memory


   VTMemory             LTMemory              AGCMemory

   LTPhysicalMemory   VTPhysicalMemory




                                                        15/25
LTMemory VTMemory AGCMemory
              comparison


                            LTMemory       VTMemory         AGCMemory

         Allocation time     Linear       Not bounded          Linear

De-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
Supporting AGCMemory




         Structures
         Runtime barriers
         Example revisited
AGCMemory Internal Structures
0xAC00
                                              method_ptr            scape_ptr

                                                                        top
                                                                        top-1
                                                             .          top-2
                             free_mem_ptr                    .
                                                             .          0

                                                        agc_stack
0x0C00
       physical memory

Chunk of physical memory:
   Objects are allocated in ascending memory addresses
   free_mem_ptr: position where the next object will be allocated
AGCstack (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
Runtime Barriers


Barrier               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
Example revisited (I)
        free_mem_ptr (0)
method_ptr


             0
             0                                      250 free bytes

scape_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
Example revisited (II)
                                free_mem_ptr (88)
method_ptr


             0                                   162 free bytes
             0

scape_ptr

       agc_stack
       top



       Object creation inside method System.out.println




                                                    21/25
Example revisited (and III)
 free_mem_ptr (0)



          0                                     250 free bytes
          0



    agc_stack
    top


Post-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
Conclusions

Existing types of regions hard to use
   Floating garbage problem


AGCMemory:
   It reduces floating garbage problem
   It improves the automatic memory management
   Easier to use than nested scopes
   It uses constant time barriers




                                                 23/25
Future work

Implementation of AGCMemory in a RTSJ open source
virtual machine
   We are using JRate


Evaluation 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
Enhancing the region model of real-time
    Java for large-scale systems



               Thanks




                                 25/25

More Related Content

PPT
Simple asynchronous remote invocations for distributed real-time Java
PPT
No Heap Remote Objects for Distributed real-time Java
PPT
A synchronous scheduling service for distributed real-time Java
PPT
PDF
[JavaOne 2011] Models for Concurrent Programming
PPT
Jvm Performance Tunning
PPTX
java memory management & gc
Simple asynchronous remote invocations for distributed real-time Java
No Heap Remote Objects for Distributed real-time Java
A synchronous scheduling service for distributed real-time Java
[JavaOne 2011] Models for Concurrent Programming
Jvm Performance Tunning
java memory management & gc

What's hot (20)

PDF
Exploiting Concurrency with Dynamic Languages
PDF
Towards an Integration of the Actor Model in an FRP Language for Small-Scale ...
PDF
[GEG1] 10.camera-centric engine design for multithreaded rendering
PDF
A Language Support for Exhaustive Fault-Injection in Message-Passing System M...
PDF
Java in flames
PPTX
General Purpose Computing using Graphics Hardware
PDF
Using Flame Graphs
PDF
Tungsten University: Setup and Operate Tungsten Replicators
PPT
Deuce STM - CMP'09
PPT
Java Performance Tuning
PDF
Tr ns802 11
PDF
Machine Trace Metrics
PDF
JCConf 2020 - New Java Features Released in 2020
PPTX
Seeing with Python presented at PyCon AU 2014
PDF
LLVM Register Allocation
PDF
Let's talk about Garbage Collection
PPT
Mpage Scicomp14 Bynd Tsk Geom
PDF
Dimemas and Multi-Level Cache Simulations
PPTX
Hp rhev-m-driver
Exploiting Concurrency with Dynamic Languages
Towards an Integration of the Actor Model in an FRP Language for Small-Scale ...
[GEG1] 10.camera-centric engine design for multithreaded rendering
A Language Support for Exhaustive Fault-Injection in Message-Passing System M...
Java in flames
General Purpose Computing using Graphics Hardware
Using Flame Graphs
Tungsten University: Setup and Operate Tungsten Replicators
Deuce STM - CMP'09
Java Performance Tuning
Tr ns802 11
Machine Trace Metrics
JCConf 2020 - New Java Features Released in 2020
Seeing with Python presented at PyCon AU 2014
LLVM Register Allocation
Let's talk about Garbage Collection
Mpage Scicomp14 Bynd Tsk Geom
Dimemas and Multi-Level Cache Simulations
Hp rhev-m-driver
Ad

Similar to Enhancing the region model of RTSJ (20)

PDF
[BGOUG] Java GC - Friend or Foe
ODP
Java 5 6 Generics, Concurrency, Garbage Collection, Tuning
PDF
Production Time Profiling and Diagnostics on the JVM
PDF
May2010 hex-core-opt
PPT
Performance tuning jvm
PDF
Performance evaluation with Arm HPC tools for SVE
PDF
Alex Smola, Professor in the Machine Learning Department, Carnegie Mellon Uni...
ODP
Java Generics
PPT
Introduction to Real Time Java
PPTX
Beirut Java User Group JVM presentation
PDF
Safe Clearing of Private Data
PPTX
Lambdas puzzler - Peter Lawrey
PPTX
7 jvm-arguments-v1
PPTX
Java Micro-Benchmarking
PPTX
JVM Memory Model - Yoav Abrahami, Wix
PDF
A race of two compilers: GraalVM JIT versus HotSpot JIT C2. Which one offers ...
PPT
memory
PPTX
Grow and Shrink - Dynamically Extending the Ruby VM Stack
PPT
PPTX
Java 7 & 8 - A&BP CC
[BGOUG] Java GC - Friend or Foe
Java 5 6 Generics, Concurrency, Garbage Collection, Tuning
Production Time Profiling and Diagnostics on the JVM
May2010 hex-core-opt
Performance tuning jvm
Performance evaluation with Arm HPC tools for SVE
Alex Smola, Professor in the Machine Learning Department, Carnegie Mellon Uni...
Java Generics
Introduction to Real Time Java
Beirut Java User Group JVM presentation
Safe Clearing of Private Data
Lambdas puzzler - Peter Lawrey
7 jvm-arguments-v1
Java Micro-Benchmarking
JVM Memory Model - Yoav Abrahami, Wix
A race of two compilers: GraalVM JIT versus HotSpot JIT C2. Which one offers ...
memory
Grow and Shrink - Dynamically Extending the Ruby VM Stack
Java 7 & 8 - A&BP CC
Ad

More from Universidad Carlos III de Madrid (8)

PPT
Tecnicas y extensiones para Java de tiempo real
PPTX
Towards a garbage collector for distributed real-time Java
PDF
A simple data muling protocol
PDF
Mejoras a la predictibilidad de la tecnología Java EE
PPTX
Remote Memory Areas for distributed real-time Java
PDF
Towards a real-time reconfiguration service for distributed Java
PPT
Pbasanta@jtres06 extendedportal
Tecnicas y extensiones para Java de tiempo real
Towards a garbage collector for distributed real-time Java
A simple data muling protocol
Mejoras a la predictibilidad de la tecnología Java EE
Remote Memory Areas for distributed real-time Java
Towards a real-time reconfiguration service for distributed Java
Pbasanta@jtres06 extendedportal

Enhancing the region model of RTSJ

  • 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. Outline Introduction Recycling Floating Garbage with AGCMemory Extending RTSJ Hierarchy Supporting AGCMemory Conclusions and future work 2/25
  • 3. Introduction (I) Good properties of Java make it suitable for large-scale systems: Portability Automatic memory management (garbage collector) Simplicity Networking support… When we introduce real-time constraints  problems with automatic memory management Garbage collector introduces unpredictable breaks in program execution  deadlines may be missed 3/25
  • 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. Introduction (and III) Our approach is a new type of region for RTSJ: AGCMemory It tries to improve the portability of regions while keeping some of the advantages of GC-techniques It maintains the Java programming style It provides the predictability of regions It reduces the number of manual changes More portable applications It enhances the reuse of code and it decreases the development time 5/25
  • 6. Recycling Floating Garbage with AGCMemory Floating garbage Using nested scopes to eliminate floating garbage Using AGCMemory to eliminate floating garbage
  • 7. Motivation: PeriodicCounter 1. import javax.realtime.* 2. public class PeriodicCounter extends RealtimeThread{ 3. public PeriodicConter(){ 4. super( null,//Schedulling par 5. new PeriodicParameters(null, 6. new RelativeTime(1000,0), //T 7. new RelativeTime(50,0), //C 8. new RelativeTime(100,0), //D 9. null,null /*Handlers*/); 10. null, //Memory parameters 11. new LTMemory(100,100), //Mem. param 12. 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-RI 19. counter++ 20. }while(waitForNextPeriod()); 21. } 22. public static void main(String s[]){ 23. new HelloPeriodicCounter(); 24. } 7/25
  • 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 PeriodicCounter 1 2 3Mem-registry.c::InvokeNewInstance()- Went out of memory 8/25
  • 9. Solving the problem with nested scopes 1. 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 scope 9. 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. 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. Nested Scopes Problems The programmer has to set up: Number of auxiliary scopes Maximum size of each auxiliary scope Other problems: Low portability High dependency on available classes Not especially intuitive (runnable objects) Runnable classes required Our solution: AGCMemory 11/25
  • 12. AGCMemory 1. import javax.realtime.* 2. public class PeriodicCounter extends RealtimeThread{ 3. public PeriodicConter(){ 4. super( null,//Schedulling par 5. new PeriodicParameters(null, 6. new RelativeTime(1000,0), //T 7. new RelativeTime(50,0), //C 8. new RelativeTime(100,0), //D 9. null,null /*Handlers*/); 10. null, //Memory parameters 11. new AGCMemory(250,250), //Mem. param 12. 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. Using AGCMemory 250 free bytes 11. new AGCMemory(300,300) 18. System.out.println(counter) 250 free bytes //preinvocation 162 free bytes //printing the counter 250 free bytes //memory releasing 250 free bytes 18. counter++ 13/25
  • 15. AGCMemory in the RTSJ class Hierarchy ImmortalMemory Memory Area HeapMemory ImmortalPhysicalMemory Scoped Memory VTMemory LTMemory AGCMemory LTPhysicalMemory VTPhysicalMemory 15/25
  • 16. LTMemory VTMemory AGCMemory comparison LTMemory VTMemory AGCMemory Allocation time Linear Not bounded Linear De-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. Supporting AGCMemory Structures Runtime barriers Example revisited
  • 18. AGCMemory Internal Structures 0xAC00 method_ptr scape_ptr top top-1 . top-2 free_mem_ptr . . 0 agc_stack 0x0C00 physical memory Chunk of physical memory: Objects are allocated in ascending memory addresses free_mem_ptr: position where the next object will be allocated AGCstack (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. Runtime Barriers Barrier 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. Example revisited (I) free_mem_ptr (0) method_ptr 0 0 250 free bytes scape_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. Example revisited (II) free_mem_ptr (88) method_ptr 0 162 free bytes 0 scape_ptr agc_stack top Object creation inside method System.out.println 21/25
  • 22. Example revisited (and III) free_mem_ptr (0) 0 250 free bytes 0 agc_stack top Post-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. Conclusions Existing types of regions hard to use Floating garbage problem AGCMemory: 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. Future work Implementation of AGCMemory in a RTSJ open source virtual machine We are using JRate Evaluation 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. Enhancing the region model of real-time Java for large-scale systems Thanks 25/25