Basanta jtr2009
•Descargar como PPT, PDF•
0 recomendaciones•376 vistas
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Basanta jtr2009
Similar a Basanta jtr2009 (20)
Más de Universidad Carlos III de Madrid
Más de Universidad Carlos III de Madrid (6)
Basanta jtr2009
- 1. Simplifying the dualized threading model of RTSJ Pablo Basanta-Val Marisol García-Valls Iria Estévez-Ayres mailto: pbasanta@it.uc3m.es http://www.it.uc3m.es/drequiem/ Este trabajo ha sido publicado en IEEE-ISORC’08 (Orlando-USA)
- 2. Roadmap 1. Introduction – Motivation 1. RealtimeThread++ extension – Interface changes – Example of use – Low level (VM) changes 1. Taking advantage of the extension – GC interference avoidance – Extended event handlers – Enhanced real-time distributed architectures 1. Empirical results – Absolute and relative penalties 1. Concluding remarks
- 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. 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. 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. Real-Time Java Centralized RTSJ Thread concurrent RealtimeThread entities NoheapRealtimeThread AsyncEventHandler BoundAsyncEventHandler Distributed DRTSJ DistributedRealtimeThread concurrent NoHeapDistributedRealtimeThread entities DistributedEventHandler Synchronization RTSJ Synchronized RealtimeQueues Signals
- 7. Real-Time Java with RealtimeThread++ Centralized RTSJ Thread concurrent RealtimeThread entities NoheapRealtimeThread AsyncEventHandler BoundAsyncEventHandler Distributed DRTSJ DistributedRealtimeThread concurrent NoHeapDistributedRealtimeThread entities DistributedEventHandler Synchronization RTSJ synchronized RealtimeQueues Signals
- 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
- 10. RealtimeThread++ in action One task printing out two messages: the first in noheap and the second in heap
- 11. RealtimeThread++ in action Evolution of the system, the active environment is the one on the top of the environment stack
- 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. 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. Integration with the garbage collector
- 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. Garbage collector priority inversion
- 17. Garbage collector priority inversion (current RTSJ approach)
- 18. Garbage collector priority inversion (with RealtimeThread++)
- 19. Enhanced RTSJ event model Currently event handler decide at creation time its relationship with the garbage collector
- 20. Session-level isolation for DRTSJ (with real-time thread++ extension)
- 21. Absolute and relative performance
- 22. Preguntas
Notas del editor
- 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.