1 / 16

Object Initialization in X10

Object Initialization in X10. Yoav Zibin David Cunningham Igor Peshansky Vijay Saraswat IBM research in TJ Watson. Initialization Can be Tricky. Reason 1: dynamic dispatching. abstract class A { A() { System.out.println (“me=“+ this. description () ); }

camdyn
Download Presentation

Object Initialization in X10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object Initialization in X10 YoavZibinDavid Cunningham Igor PeshanskyVijay Saraswat IBM research in TJ Watson

  2. Initialization Can be Tricky • Reason 1: dynamic dispatching abstract class A { A() {System.out.println(“me=“+this.description()); } abstract String description(); } class B extends A { intb = 2; public String description(){ return “b=“+b; } }

  3. Initialization Can be Tricky • Reason 2: leaking a raw/uninitialized object class A { public static HashSet set = new HashSet(); A() {set.add(this); } } class B extends A { final intb = 2; }

  4. Initialization Can be Tricky • Reason 3: concurrent and distributed code class Fib { val fib2:Int; // fib(n-2) val fib1:Int; // fib(n-1) valfib:Int; // fib(n) def this(n:Int) { finish { async { val p = here.next(); fib2 = at(p) n <=1? 0 : new Fib(n -2).fib; } fib1 = n <=0? 0 : n<=1? 1 : new Fib(n -1).fib; } fib = fib2+fib1; } }

  5. Desired Initialization Properties • Cannot read uninitialized fields • C++: uninitialized fields have unspecified value • Java: fields are zero initialized • Final fields • Written exactly once • Single value for final fields • Immutable objects are thread-safe • Simple (initialization order is clear) • Flexible (ability to express common idioms) • Type safe

  6. X10 Initialization Rules • Hard-hat design • Strict: E.g., mostly no dynamic dispatching , no leaking this. • Pros: has the desired properties (simple, type safe, etc) • Cons: Less flexible, e.g., cannot express cyclic immutable data-structures

  7. Rules Overview • Demonstrate the rules by examples • Initialization is a cross-cutting concern • Dynamic dispatching and leaking this • Default/zero value • Properties • Generics • Concurrent and distributed programming • More in the paper: • Inner classes, exceptions, closures, structs, serialization, cloning, and more…

  8. this escaping • this is raw in non-escaping methods (constructors and methods called from them) • A raw this cannot escape or be aliased. class A { val f:Int; def this() { m1(); f = m3(); LeakIt.leak(this); // ERR } private def m1() { m2(); } final def m2() {} @NoThisAccessdef m3() = 1; }

  9. Has-zero • Definition of has-zero • A type has-zero if it contains the zero value (which is either null, false, 0)(A struct and type parameter may also has-zero) • A var field that lacks a field initializer and whose type has-zero, is implicitly added a zero initializer. class A { val i0:Int; //ERR var i1:Int; var i2:Int{self!=0}; //ERR }

  10. Properties • Properties are final fields that are initialized first using property(...); class A(a:Int) {} class B(b:Int) {b==a} extends A { val f1 = a+b; def this(x:Int) { super(x); val i1 = super.a; val i2 = this.f1; //ERR property(x); val i3 = this.f1; } } super init Field initializers are executed after property(…) Properties init Field init

  11. Generics • haszero type predicate class B[T] {T haszero } { var f1:T; val f2 = Zero.get[T](); } class Usage { var b1:B[Int]; var b2:B[Int{self!=0}]; //ERR } class Array[T] { def this(size:Int) {T haszero} {…} def this(defaultElement:T,size:Int) {…} }

  12. Concurrent programming • finish and async • A constructor must finish assigning to all fields class A { val f1:Int; val f2:Int; def this() { async f1 = 2; // ERR finish { async f2 = 3; } } }

  13. Distributed programming • at shifts execution to another place • A raw this cannot be captured by an at. class A { val f:Int; def this() { at (here.next()) this.f = 1; //ERR: this escaped } }

  14. Definite assignment class A { var i:Int{self!=0} , j:Int{self!=0}; def this() { finish { asyncWriteI(); // asyncAssigned={i} writeJ(); // ERR } // assigned={i} writeJ();// assigned={i,j} } private def asyncWriteI () {// asyncAssigned={i} asynci=1; } private def writeJ() {// reads={i} assigned={j} if (i==1) writeJ(); else this.j = 1; } }

  15. Previous work • Java • C++ • Non-null types • Masked types (Qi and Meyers) • Detector uninitialized fields

  16. Conclusion • Java and C++ initialization is error-prone • X10 initialization design • Strict: protects from errors • Simple • Flexible (but cannot express cyclic immutability) • Type safe • Final fields has a single value • See paper for alternative designs (e.g., proto) • Questions?

More Related