Dear DDJ,
Mark Mitchell's article "Type-Based Alias Analysis" (DDJ, Oct.2000) was refreshing reading after having programmed for some 12 years in an aliasing-free concurrent language. However, I have some points to add:
- Mitchell does not directly state that aliasing can also happen in pointer-less languages. When an object in such a language is used by its name only it may still be treated by reference by the compiler, thus opening for aliasing errors.
- Aliasing-free code could be fast, but aliasing of objects could be fatal! In the Java example below x=x+(x-x)
may correctly be x but fatally zero when c1 is aliased.
class thing { // "{}" became ? in layout in magazine // By Peter Welch, Univ. of Kent at Canterbury, UK int x; public thing (int v) {x = v;} public static void harmless (thing t1, thing t2) { t1.x = t1.x + t2.x; t1.x = t1.x - t2.x; } } class alias { public static void main (String args[]) { thing c1 = new thing(10); thing c2 = new thing(20); thing.harmless (c1,c2); // c1.x=10 c2.x=20 thing.harmless (c1,c1); // c1.x=0 has become 0! } } - Aliasing may also be a wanted trait. Passing by reference and doubly-linked lists are examples.
- Mitchell mentions that the C9X "restrict" does not prohibit the programmer from making aliasing errors. With occam the compiler takes me at the subtlest places, where I would not have imagined problems - but then there is no "restrict"-type decoration, ALL variables are verified for aliasing errors, and the compiler can therefore always assume aliasing-free code.
- I have just recently (At a SIG at the CPA 2000 conference: http://wotug.ukc.ac.uk/cpa2000) learned that if one could control aliasing in an object-oriented language, one could also control garbage collection. An object free of aliasing can be de-allocated in unit-time once it goes out of scope for the single only referencer of that particular object.
Oyvind Teig
