Pbasanta@jtres06 extendedportal

17
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/

Transcript of Pbasanta@jtres06 extendedportal

Page 1: Pbasanta@jtres06 extendedportal

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 GROUPUniversidad Carlos III de Madrid

http://www.it.uc3m.es/drequiem/

Page 2: Pbasanta@jtres06 extendedportal

2

Outline of the presentation

IntroductionRelated workThe problem of using the portalsExtendedPortal

API Internal implementations

The cost of the portalsConclusions

Page 3: Pbasanta@jtres06 extendedportal

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.

Page 4: Pbasanta@jtres06 extendedportal

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

Page 5: Pbasanta@jtres06 extendedportal

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

Page 6: Pbasanta@jtres06 extendedportal

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

Page 7: Pbasanta@jtres06 extendedportal

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

Page 8: Pbasanta@jtres06 extendedportal

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

Page 9: Pbasanta@jtres06 extendedportal

9

Internals: Data structure

Extremely easyPointers to get the reference

One object attributeOne 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

Page 10: Pbasanta@jtres06 extendedportal

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.

Page 11: Pbasanta@jtres06 extendedportal

11

Internals: unsetting the portal

All regions of the scope stack are decremented -(2):-1 - when the reference is hard.

Page 12: Pbasanta@jtres06 extendedportal

12

Internals: getting the portal

Only if the creation context of c is the invoking thread scope stack one, the access is granted. LIMITATION.

Page 13: Pbasanta@jtres06 extendedportal

13

Internals: Entering the portal

It may used to ensure that the object access never fails, entering the creation context before reading the reference

Page 14: Pbasanta@jtres06 extendedportal

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.

Page 15: Pbasanta@jtres06 extendedportal

15

Internals: Hardening a weak reference

As in the destruction, the scope stack is decremented in order to allow the reference destruction.

Page 16: Pbasanta@jtres06 extendedportal

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

Page 17: Pbasanta@jtres06 extendedportal

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