ExtendedPortal provides a mechanism for safely violating the assignment and single parent rules of the Real-Time Specification for Java (RTSJ). It does this through an extended portal API that allows storing and retrieving object references while maintaining the creation context through a scope stack. Internally, it uses pointers to references and a scope stack, incrementing and decrementing the stack to control access. Extended portals enable more flexible programming but can potentially cause memory leaks by keeping regions live longer than intended.

1. ExtendedPortal: Safe violation of the
assignment rule and single parent rule
enforcement
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. Outline of the presentation
 Introduction
 Related work
 The problem of using the portals
 ExtendedPortal
 API
 Internal implementations
 Thecost of the portals
 Conclusions
2

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. 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. 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. 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. The complexity of accessing to and
object allocated using the portal
Complexity of accessing to an arbitrary object using portals: Θ(n)
where n the nesting level
7

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. 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. 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. Internals: unsetting the portal
All regions of the scope stack are decremented -(2):-1 - when the
reference is hard.
11

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. 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. Internals: Weakening a hard
reference
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. Internals: Hardening a weak
reference
As in the destruction, the scope stack is decremented in order to
allow the reference destruction.
15

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. 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