ExtendedPortal: Safe violation of theassignment rule and single parent ruleenforcement     Pablo Basanta-Val, Marisol Garc...
Outline of the presentation  Introduction  Related work  The problem of using the portals  ExtendedPortal    API    ...
Introduction    The assignment and single parent rules of RTSJ        One of the mayor differences between plain Java an...
Introduction: our experience  Implementing    DREQUIEMI a RTRMI approach   to the distributed real-time Java      There ...
Some related work    Patterns to program with the scoped memory        Corsaro [JTRES04]: singleton, leader-follower, tu...
and more closer related work    Borg [JTRES04] reference objects        Improved navigation mechanism        But no pos...
The complexity of accessing to andobject allocated using the portal  Complexity of accessing to an arbitrary object using ...
ExtendedPortal API  -setPortal never fails  -getPortal does not grant access in unsafe    situations  -enter may be used t...
Internals: Data structure  Extremely    easy    Pointers   to get the reference       One object attribute       One n...
Internals: setting the portal  All regions of the scope stack are incremented –(2):+1 - to forbid the  prior to time destr...
Internals: unsetting the portal  All regions of the scope stack are decremented -(2):-1 - when the  reference is hard.    ...
Internals: getting the portal   Only if the creation context of c is the invoking thread scope stack   one, the access is ...
Internals: Entering the portal   It may used to ensure that the object access never fails, entering   the creation context...
Internals: Weakening a hardreference  As in the destruction, the scope stack is decremented in order to allow the referenc...
Internals: Hardening a weakreference   As in the destruction, the scope stack is decremented in order to   allow the refer...
The cost of having extended portals  Performance      Not a really issue           In DREQUIEMI one get and one enter p...
Conclusions and future work    The portals sometimes are hard when we want to     violate the single parent rule an when ...
Upcoming SlideShare
Loading in...5
×

Pbasanta@jtres06 extendedportal

108

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Pbasanta@jtres06 extendedportal

  1. 1. ExtendedPortal: Safe violation of theassignment rule and single parent ruleenforcement Pablo Basanta-Val, Marisol García-Valls, Iria Estevez- Ayres and Carlos Delgado-Kloos DREQUIEM LAB. / GAST GROUP Universidad Carlos III de Madrid http://www.it.uc3m.es/drequiem/ 1
  2. 2. Outline of the presentation  Introduction  Related work  The problem of using the portals  ExtendedPortal  API  Internal implementations  Thecost of the portals  Conclusions 2
  3. 3. Introduction  The assignment and single parent rules of RTSJ  One of the mayor differences between plain Java and the region based models  Some new programming patterns are required: special programming techniques, the copy pattern, the portal  Are those techniques sufficient?  It seams that one of the goals of RTSJ 1.1 is to provide a mechanism able to violate the assignment  Some applications are to hard to code  One ironic example: the implementation of a region based distributed middleware  Implementations results, mainly produced in the context of RTZen, come with a new set of programming paradigms and also some authors, Borg, suggested the necessity of having new mechanisms. 3
  4. 4. Introduction: our experience  Implementing DREQUIEMI a RTRMI approach to the distributed real-time Java  There easy cases where a mechanism to violate the single parent rule is not necessary  When is allocated in scoped memory  But the general case it is no so easy  Objects allocated in high level scoped memory instances whose access requires many linked pointers  So, we decided to developed our extension: extended portal  References are always write, weak and hard semantics 4
  5. 5. Some related work  Patterns to program with the scoped memory  Corsaro [JTRES04]: singleton, leader-follower, tunnels  Benotwitz [JTRES03]: use of serialization mechanism to perform automatic copies  The copy pattern: if you cannot hold a reference just maintain a copy  Pizlo [ISORC04]: the usage of portals and wedge threads to avoid the destruction of regions  They are 100% compatible with the current reference model  The portal mechanism is used to avoid the assignment rule limitations 5
  6. 6. and more closer related work  Borg [JTRES04] reference objects  Improved navigation mechanism  But no possibility to access to the stored reference and no hard semantics  jTime pinning-scopes [JTIME02]  Improved navigation, no linked portals need to access the creation context  But the reference in the type of references that may be maintained by the model  Higuera-Toledano [ISORC06, JTRES04] region model  A medium level navigation mechanism that enforces the single parent rule  But silent about the violation of the assignment rule  Extended portals  Medium level navigation, enforcing the single parent rule  Any reference may be stored in a extended portal 6
  7. 7. The complexity of accessing to andobject allocated using the portal Complexity of accessing to an arbitrary object using portals: Θ(n) where n the nesting level 7
  8. 8. ExtendedPortal API -setPortal never fails -getPortal does not grant access in unsafe situations -enter may be used to access to the creation context of an object 8
  9. 9. Internals: Data structure  Extremely easy  Pointers to get the reference  One object attribute  One native reference A scope stack to remember the creation context of the reference  Main operations done over them:  setting, unsetting, getting, weakening, hardening an extended portal 9
  10. 10. Internals: setting the portal All regions of the scope stack are incremented –(2):+1 - to forbid the prior to time destruction of the object. 10
  11. 11. Internals: unsetting the portal All regions of the scope stack are decremented -(2):-1 - when the reference is hard. 11
  12. 12. Internals: getting the portal Only if the creation context of c is the invoking thread scope stack one, the access is granted. LIMITATION. 12
  13. 13. Internals: Entering the portal It may used to ensure that the object access never fails, entering the creation context before reading the reference 13
  14. 14. Internals: Weakening a hardreference As in the destruction, the scope stack is decremented in order to allow the reference destruction but the reference and the scope stack are not destroyed. 14
  15. 15. Internals: Hardening a weakreference As in the destruction, the scope stack is decremented in order to allow the reference destruction. 15
  16. 16. The cost of having extended portals  Performance  Not a really issue  In DREQUIEMI one get and one enter per remote invocation. Many assignment rule verifications done in between.  Garbage collection detection  Hard references: They may produce region lekages  Weak references: No problems.  Note: current portals does not produce region leaks 16
  17. 17. Conclusions and future work  The portals sometimes are hard when we want to violate the single parent rule an when want to access to objects allocated within scoped memory  Extended portals provide a reasonable mechanism to access to of a reference but at the cost of introducing more memory leaks  A new potential type of memory leak: the leakage of regions  Some ongoing research  Θ(1) implementation support  enter removal 17
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×