Simplifying the dualizedthreading model of RTSJ                   Pablo Basanta-Val                  Marisol García-Valls ...
Roadmap1.   Introduction     –   Motivation1. RealtimeThread++ extension     –   Interface changes     –   Example of use ...
Introduction• Java is a successful high-level language   – Bytecode portability, garbage collection, clear syntax, a numbe...
Current Status of Real-Time Java• Specifications   – Real-Time Specification for Java (RTSJ)   – Distributed Realtime Spec...
RealtimeThread++• An extension not identified in JSR-282 (RTSJ 1.1)• RTSJ offers two types of real-time threads:       • R...
Real-Time JavaCentralized       RTSJ                Threadconcurrent                        RealtimeThreadentities        ...
Real-Time Java                  with RealtimeThread++Centralized       RTSJ                Threadconcurrent               ...
RealtimeThread++: changes• One thread is initially running in either heap or noheap  environments   – By default, in its i...
RealtimeThread++: full API
RealtimeThread++ in actionOne task printing out two messages: the first in noheapand the second in heap
RealtimeThread++ in actionEvolution of the system, the active environmentis the one on the top of the environment stack
Required underlying support• Activation and deactivation of reading barrier typically associated with  a NhRtThs    – Low ...
Runtime checking barriers          (examples) Runtime barrier that changes the behavior from heap to no-heap .Runtime barr...
Integration with the garbage          collector
Taking advantage of the extension– Sharing data   • Among heap and no-heap entities using enterNoHeap– Enrichment of the c...
Garbage collector priority inversion
Garbage collector priority inversion     (current RTSJ approach)
Garbage collector priority inversion       (with RealtimeThread++)
Enhanced RTSJ event model Currently event handler decide at creation time its relationship with the garbage collector
Session-level isolation for DRTSJ  (with real-time thread++ extension)
Absolute and relative performance
Preguntas
Upcoming SlideShare
Loading in...5
×

Basanta jtr2009

137

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
137
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Goal: introduce the article, saying you are the presenter and all question to pablo
  • How we “organized” the paper as follows: firstly, I will put into context, highlighting advantages and motivation. And then, technical aspects, as could be interfaces, and example of use and the low level changes required to support the model. And I will finish introducing
  • Java is excellent as general purpose language. (See reports show it) And this type of advantages are trying to extended to the area of real-time systems. Image for a moment, this
  • Ok, if we have to define where we area now, I can see that we have carried out an important work defining basic necesities. We have developed specifications for real-time as for example the RTSJ (artiesllei) or its distributed counterpart (dartiesllei). But that’s not all, we also have real-time virtual machines and products that can be used to develop our applications. Just to cite some of them, I have put them in this slide. And we have also adapted our developed plugins to work with this specifications for the most popular devolpment environments. That is netbeans and also eclipse (I’klips) So … perhaps, it is time for the improvements How can we improve the current RTSJ? Which are their lacks? How do we improve it? This is the goal of the JSR-282: “it addresses some of the simpler enhancements that have been requested in the RTSJ ” grouping them into three areas: scheduling improvements, memory improvements, and other improvements So perhaps we, at the real-time programming community, are living a period of time for the improvements. Ok, we have already And this is the specific goal of the two hundred and eitghty two specification lleiesar group. It has gather (gada) the requirements of the community. Basically it organize the changes in three groups: scheduling, memory and other changes.
  • In this context, we may understand the real-time thread++ extesion as a very simple but interesting extension that was not previously identified by the lleiesar group. The idea is that RTSJ currently offfers two types of threads, Noheap an real time threads which may not be which are hindering (entorpercir, hinda) the development of applications more simplily.
  • Ok, This is just a fast look of realtime Java we can see how it have nine concurrent entities: five of RTSJ plus the three of DRTSJ. And apart from that we have three sincronization mechanisms: synchrononized, realtime queues and also the signals.
  • Notes: enter*Heap: save its relationship with the garbage collector, changes to heap or noheap, execute the runnable object and restores the previous status isRunningInHeap helps us to discover in which one of the two environments is running the invoking thread
  • Key idea: What we need from a virtual machine. Mainly, there are there issues we have to consider when we want to implement this idea: The first is that it requires to gain some control on the management on the run-time barrier, executed by as well as a mechanism (2) to check local variables. Finally the third (3) is that sometimes (it depends on the virtual machine implementation), it may require changes in the internals of the garbage collector. Next, I will
  • Here you can see an example of some runtime barriers you need in your code. First changes from heap to no heap and the second from no-heap to heap.
  • And here you can see an example of how you move threads from one queue into the another. This shows you how
  • I’ve already introduced you the interface together with some details on the implementation of RTSJ
  • IDEA: Garbage collections may interrupt when NHRTS are accessing to a shared object. A common problem, for example when implementing an RT-RMI
  • IDEA 1: Using current RTSJ aproach to solve the problem. IT works, but you need one extra thread and a queue.
  • IDEA 2:Using the extension. I don’t need a queue or an auxiliary thread, you only need a Runnable object.
  • And here you see how an event may be impor
  • This is second possibility, in this case what we want is to avoid the garbage collector interference, using the two method to achieve the desired level of isolation. It is easier to implement than the previous one.
  • Goal: introduce the article, saying you are the presenter and all question to pablo
  • So … perhaps, it is time for the improvements How can we improve the current RTSJ? Which are their lacks? How do we improve it? This is the goal of the JSR-282: “it addresses some of the simpler enhancements that have been requested in the RTSJ ” grouping them into three areas: scheduling improvements, memory improvements, and other improvements So perhaps we, at the real-time programming community, are living a period of time for the improvements. Ok, we have already And this is the specific goal of the two hundred and eitghty two specification lleiesar group. It has gather (gada) the requirements of the community. Basically it organize the changes in three groups: scheduling, memory and other changes.
  • This is the first solution: using queues to isolate middleware communications Problem: hard to implement.
  • Basanta jtr2009

    1. 1. Simplifying the dualizedthreading model of RTSJ Pablo Basanta-Val Marisol García-Valls Iria Estévez-Ayres mailto: pbasanta@it.uc3m.eshttp://www.it.uc3m.es/drequiem/ Este trabajo ha sido publicado en IEEE-ISORC’08 (Orlando-USA)
    2. 2. Roadmap1. Introduction – Motivation1. RealtimeThread++ extension – Interface changes – Example of use – Low level (VM) changes1. Taking advantage of the extension – GC interference avoidance – Extended event handlers – Enhanced real-time distributed architectures1. Empirical results – Absolute and relative penalties1. Concluding remarks
    3. 3. Introduction• Java is a successful high-level language – Bytecode portability, garbage collection, clear syntax, a number of libraries, …. – Productivity may be higher than with other languages (C/C++)• Java has extended its radius of action to real-time systems – Ideally: real-time portability, real-time automatic memory management, and real-time libraries – And also: lower development times, and improved maintainability
    4. 4. Current Status of Real-Time Java• Specifications – Real-Time Specification for Java (RTSJ) – Distributed Realtime Specification for Java (DRTSJ)• Compliant virtual machines – Sun’s JRTS, Aicas’s Jamaica, TimeSys’s JTime, IBM Real-Time Websphere, Purdue’s OVM, …• Plug-ins for development environments – Netbeans (Sun) and Eclipse (IBM, Aicas)
    5. 5. RealtimeThread++• An extension not identified in JSR-282 (RTSJ 1.1)• RTSJ offers two types of real-time threads: • RealtimeThread (RtThs) and NoHeapRealtimeThreads (NhRtThs)• Reducing unnecessarily the language expressiveness – RtThs suffer the garbage collector whereas NhRtThs cannot use the heap – A general purpose application may require both types of support• Why don’t a simplification in this model? – One unique type of thread that decides its relationship with the garbage collector and the heap at runtime – Benefits: a more flexible specification and better synchronization models.
    6. 6. Real-Time JavaCentralized RTSJ Threadconcurrent RealtimeThreadentities NoheapRealtimeThread AsyncEventHandler BoundAsyncEventHandlerDistributed DRTSJ DistributedRealtimeThreadconcurrent NoHeapDistributedRealtimeThreadentities DistributedEventHandlerSynchronization RTSJ Synchronized RealtimeQueues Signals
    7. 7. Real-Time Java with RealtimeThread++Centralized RTSJ Threadconcurrent RealtimeThreadentities NoheapRealtimeThread AsyncEventHandler BoundAsyncEventHandlerDistributed DRTSJ DistributedRealtimeThreadconcurrent NoHeapDistributedRealtimeThreadentities DistributedEventHandlerSynchronization RTSJ synchronized RealtimeQueues Signals
    8. 8. RealtimeThread++: changes• One thread is initially running in either heap or noheap environments – By default, in its instantiation, NhRtThs and NhDRtThs run in noheap memory whereas RtThs run in heap• One thread may change at runtime its relationship with the garbage collector – We may change it, temporally, nesting a heap (with enterHeap) or a noheap (with enterNoHeap) runnable object
    9. 9. RealtimeThread++: full API
    10. 10. RealtimeThread++ in actionOne task printing out two messages: the first in noheapand the second in heap
    11. 11. RealtimeThread++ in actionEvolution of the system, the active environmentis the one on the top of the environment stack
    12. 12. Required underlying support• Activation and deactivation of reading barrier typically associated with a NhRtThs – Low level interaction with the virtual machine required• The check of local variables (for NH to H changes) – Easy to obtain in a portable way.• Modification of the relationship maintained with the garbage collector – Sometimes, NhRtThs have privileges when garbage collector scans their frame stack
    13. 13. Runtime checking barriers (examples) Runtime barrier that changes the behavior from heap to no-heap .Runtime barrier that changes the behavior from o no-heap to heap
    14. 14. Integration with the garbage collector
    15. 15. Taking advantage of the extension– Sharing data • Among heap and no-heap entities using enterNoHeap– Enrichment of the current RTSJ • Giving more flexibility to event-handler programming– Enrichment of the ongoing DRTSJ • Eases some architecture implementations
    16. 16. Garbage collector priority inversion
    17. 17. Garbage collector priority inversion (current RTSJ approach)
    18. 18. Garbage collector priority inversion (with RealtimeThread++)
    19. 19. Enhanced RTSJ event model Currently event handler decide at creation time its relationship with the garbage collector
    20. 20. Session-level isolation for DRTSJ (with real-time thread++ extension)
    21. 21. Absolute and relative performance
    22. 22. Preguntas
    1. Gostou de algum slide específico?

      Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

    ×