Sharing Objects by Read-Only References - Semantic Scholar

Sharing Objects by Read-Only References Mats Skoglund Presented by Nathalie Kellenberger

Summary • Problem: representation exposure – visibility based protection can be circumvented Î method returns reference to private field Î all references have same rights

• Solution: transitive read-only construct – safely export of objects by reference – even of subobjects from a compound object

Overview • • • • • • • •

Motivation Transitive State Modes Mode System Read-only Properties Comparison Conclusion Discussion

Motivation Person

Address

Address addr

String street

Person friend

int number

getFriend(...)

String city

setAddress(...) getAddress( ) Person me = ... ;

// new Person is created

Person friend = me.getFriend( );

// get friend of mine

me.setAddress(...);

// ok to change own address

friend.setAddress(...);

// NOT ok to change friends address

Transitive State (1) • local state: – values of the object‘s member variables (fields)

• transitive state: – local state plus – transitive states of all member variables recursively – i.e. all objects to which the fields refer recursively

Transitive State (2) • local state: – [addr,friend]

• transitive state: – – – – – –

Person

Address

addr friend

street number city

[addr,friend] U [addr.street,addr.number,addr.city] U [friend.addr] U [friend.addr.street,friend.addr.number,friend.addr.city] U [friend.friend] U [friend.friend.addr] U and so on

• is finite at programming time

Modes (1) • write reference: – like ordinary reference – invoke any method

• read reference: – invoke only methods which don‘t change transitive state – creation of new objects allowed in invoked method • created object is always write

– allows change of objects not in transitive state in invoked method – assigning of a new reference allowed

• context reference: – depends on context of the method – becomes write in write context and read otherwise

Modes (2) - context • context of a method – mode of reference method was invoked on

• state of context variable may be changed – if the change is initiated from a write reference

• gives more flexibility! • In the motivational Example: ... context Address getAddress( ) { ... } ... write Person me = ... read Person you = me.getFriend( ); write Address mine = me.getAddress( ); //getAddress returns write read Address yours = you.getAddress( );// getAddress returns read

Modes (3) - Overview • • • • •

method : read | write local variable: read | write | context method return: read | write | context field: read | context formal parameter: read | write

Modes (4) - methods • System rejects methods declared as read if they – – – –

change target objects local state invoke write method on targets transitive state return write reference to targets transitive state pass write reference to targets transitive state

Î such methods have to be declared write! Î write method may only be invoked on write reference

Î all others are read and should be declared so Î you may invoke read method on write reference

Modes (5) • fields – can only be read or context – with write protection would be already lost!

• formal parameters – can only be read or write – system has to check if method is read or write • mode of formal parameters has to be known

Example (1) public class Person { private read Person friend; private context Address addr; public read Person getFriend( ):read { return this.friend; } public context Address getAddress( ):read { return this.addr;} public void setAddress(write Address a):write { this.addr = a; } } public class Address { private context String street; private context int number; private context String city; } write Person me = ... ; me.setAddress(...); friend.setAddress(...);

me write

addr

friend read

addr

read Person friend = me.getFriend( );

Example (2) you public class Person { write private read Person friend; private context Address addr; me.friend public Person( ):write { this.friend = this; } read public Person(read Person f):write { this.friend = f; } public void setAddress(write Address a):write { this.addr = a; } } write Address add = new Address(...); write Person you = new Person( ); you.setAddress(add); write Person me = new Person(read you); read Person he = read new Person( ); write Person her = new Person(he);

Person

//new object is always write //write method on write reference //cast you to read-only //new object as read needs cast

Mode System (1) • system is extension of type system – presented as extension of a subset of Java – no inheritance for simplicity of presentation Î statically checkable

• reference transfers controlled by modes – assignments, parameter passing, method returns

• modes are only abstract entities – need no runtime representation – shown by dynamic semantics • with big-step operational semantic • modes are not involved in evaluation of the program

Î no runtime and memory overhead

Mode System (2) - Simplifications – – – – – – – – – – – –

methods are public fields are private, only accessible through this all expressions evaluate to values value is a reference or null only one single parameter to method allowed parameter is treated as local variable this is treated as local variable this is always context this can‘t be assigned to no constructors fields of newly created objects are initialised to null value of last expression in method is return value

Read-only Properties (1) • read reference can‘t be used to change transitive state – transitive state of object doesn‘t change during an evaluation – extending store with new object Î transitive state of all other objects in the store remains unchanged read barrier read access write access transitive state of object

Read-only Properties (2) • starting configuration – without any write references to „protected“ object p

• safe path – path from object to p goes through a field declared as read

• safe value – – – –

value is null or value is read reference or (value not in transitive state of p and only safe paths from value to p)

• safe stack – all variables on stack contain save values

• everything with respect to a protected object p

Read-only Properties (3) • Read-only Theorem – starting configuration holds • is configuration with safe stack with respect to an object

– evaluate expression with a safe stack • with respect to an object and a store

Îtransitive state of object doesn‘t change • with respect to that store

Î resulting stack is also a safe stack Î result of evaluation is a save value Î evaluation doesn‘t create any new unsafe paths • from any object in store to transitive state of protected object

• proof by structural induction

Comparison •

const in C++ – protects only local state – can be cast away

•

Interfaces in Java – can be downcasted to real type of object Î any method may be invoked

•

Flexible Alias Protection – objects not in transitive state can‘t be changed

•

Functional Methods (Universes) – no object can be changed – no creation of new objects

•

JAC – readonly supertype – dependency on inheritance and strong type system – dynamic binding must be considered

Conclusion • objects not in transitive state can be changed • objects can be created – allows Factory Pattern

• syntactical overhead is high – programmer has to annotate everything Î possible solution: introduce default modes • • • •

all fields as context everything else treated as write annotate only read implicit mode conversion from write to read

Discussion