Alternativas en la Evaluación

In the following we wish to illustrate the system by showing the details of the analysis of the programs for copying and appending lists from Figures 3.1 and 3.2.

Copying lists

We wish to analyse the heap-space requirements of the methodcopy(), which is equal to the length of the list to be copied plus 1, as we have seen before. Recall the definition ofcopy() in class Cons:

Li st co py () {

let res = new Co ns () in

let _ = res . el em <- t his. e lem in

let _ = res . ne xt <- t his. n ext . c opy () in r e t u r n res ;

}

For each node of the list, a new node is created, the rest of the list is copied recursively and the new node’s element and pointer to the next node in the list are updated.

Each node of the original list needs to have enough potential to pay for the creation of the new node. This requirement is captured in the constraint

♦(Consvself_)≥♦(Consvres_{) + 1, wherev}

self is the view variable that corresponds

to the argument this and vres is the view variable corresponding to the re-

sulting list. Recall that for simplicity we assume that every object can be allocated in only one cell of the heap.

Moreover, since the method is called recursively with the next item in the list, the potential of the next node must be greater or equal than the potential of the current node. More generally, the refined type of the next node must be a subtype of the refined type of the current node, which is expressed in the constraint Aget_(Consvself_,next) v_v

self. There are no restric-

tions to the potential of the resulting node but its refined type should be a subtype of the refined type of its next node (vresvAget(Consvres,next)).

In summary, the RAJA polymorphic method type of the method copy() is the following:

Consvselfq1/q2

−−−→Listvres _{& A}get_(Consvself_,next)vv

self∧vres vAget(Consvres,next)

∧_♦(Consvself_)≥♦(Consvres_{) + 1}

Now recall the definition ofcopy() in class Nil:

Li st co py () {

r e t u r n new Nil () ; }

The variable this must pay for the object creation, thus, the polymorphic type for this method is:

Nilvselfq1/q2

The body of the methodcopy() in classListis justnull, since this method is not supposed to be called. Thus, there are no restrictions to this method’s type. However, the analysis would not be sound if the method’s polymorphic type contained no constraints at all because an object of type Listcan have dynamic type Cons, causing that the actual method to be executed at run- time is the methodcopy of class Cons, leading to unpredictable heap-space consumption. Hence the correct type for copyinList is built by adding the constraints of thecopy method in the subclasses Cons and Nil:

Listvself₋q₋₋1/q_→2_Listvres _{& A}get_(Consvself_,next)v_v

self∧vresvAget(Consvres,next)

∧_♦(Consvself_)≥♦(Consvres_{) + 1}

∧_♦(Nilvself_)≥♦(Nilvres_{) + 1}

Recall that the mainmethod calls thecopy method with the input list l: c l a s s Ma in {

Li st ma in ( Li st l ) { r e t u r n l . cop y () ; }

}

It is intuitively clear that the heap-space consumption of main is just the heap-space consumption of the copy method. In fact, the constraints of method calls consist of the constraints of the called method after variable renaming. We obtain the following type formain:

Mainvself_;Listvl₋q₋₋1/q_→2_Listvres _{& A}get_(Consv_,l _next)v_v

l∧vresvAget(Consvres,next)

∧_♦(Consvl_)≥♦(Consvres_{) + 1}

∧_♦(Nilvl_)≥♦(Nilvres_{) + 1}

It is not hard to see that the valuation

π = ({v_self 7→rich,vl7→rich,vres7→poor},{q1 7→0, q2 7→0}

builds the best possible solution for the constraints of all methods, where rich andpoor are the following views:

♦(·) rich poor

List 0 0

Nil 1 0

Cons 1 0

Main 0 0

Consrich Conspoor Aget(·,next) rich poor Aset(·,next) rich poor

The namesrichandpoorwere chosen for remarking that some classes under the view rich have potential 1 and the classes under the view poor have potential 0. We could compare potential with money metaphorically, since you can spend it for paying for object creation. In this sense a view with some potential can be said to be “rich” and a view with no potential to be “poor”. Notice that we could visualise the viewsrich and pooras follows:

List<rich> potential = 0

Cons<rich> potential = 1 next: List<rich, rich>

Nil<rich> potential = 1 Main<rich> potential = 0 view rich List<rich> potential = 0 Cons<rich> potential = 1 next: List<rich, rich>

Nil<rich> potential = 1 Main<rich> potential = 0 List<poor> potential = 0 Cons<poor> potential = 0 next: List<poor, poor>

Nil<poor> potential = 0 Main<poor> potential = 0 view poor List<poor> potential = 0 Cons<poor> potential = 0 next: List<poor, poor>

Nil<poor> potential = 0

Main<poor> potential = 0

We then obtain the following monomorphic RAJA method types: M(List,copy) = Listrich−→0/0Listpoor

M(Cons,copy) = Consrich0/0

−→Listpoor

M(Nil,copy) = Nilrich−→0/0Listpoor M(Main,main) = Mainrich;Listrich0/0

−→Listpoor

These types state thatcopyis only defined inListrich_,Nilrich_andConsrich_{, but}

not in, e.g., Listpoor and the potential of this will be consumed. The return value will be of type Listpoor hence carry potential 0. Moreover, since the type of the argumentlin themainmethod isListrich, the methodcopycan be called and the potential ofl will be consumed, which is equal to the length of the list plus 1. This is the overall potential consumed by the program which is equal to its heap-space consumption.

Now, why is the potential of a list of typeListrich equal ton+ 1, whenn is the length of the list? Suppose thatl points to a list of length 5.

l ↓

Cons Cons Cons Cons Cons Nil

The potential is calculated as the sum over all access paths starting from land not leading tonull. In this case, these access paths are

• ~p1=l

• ~p2=l.next

• ~p4 =l.next.next.next

• ~p5 =l.next.next.next.next

• ~p6 =l.next.next.next.next.next

Each of these has a dynamic type: Cons for ~p1 to p~5 and Nil for ~p6.

Each of them also has a view that can be computed by chaining the view of l along the get views, which is the view rich in each case. For each access path, we now look up the potential annotation of its dynamic type under its view. It equals 1 in every case given♦Consrich

=♦Nilrich

= 1 , yielding a sum of 6.

Appending lists

Now let us look at the analysis of the program for appending lists imper- atively in more detail. Recall the definition of the method appAuxin class Cons.

Co ns a p p A u x ( Li st y , Co ns de st ) { let _ = des t . nex t <- thi s in

r e t u r n thi s. ne xt . a p p A u x ( y , th is) ; }

Here we wish to focus on how the system handles aliasing. Notice that the variablethisis used three times in the method’s body, hence its potential has to be shared among all occurrences for the analysis to be sound. The view variable corresponding tothisis againvself and the view variable corre-

sponding todestisvdest. Then, we obtain the constraintvself vvself⊕vself⊕

vdest which implies that ♦(Consvself)≥♦(Consvself) +♦(Consvself) +♦(Consvdest)

must hold. Notice that this implies that ♦(Consvself_{) = 0.}

Moreover we get the constraint vself vAset(Consvdest,next) for the update dest.next <- this to be correct and the constraint Aget(Consvself_{,next) v}

vself since the method is called recursively with this.next. The following

valuation builds a solution for these constraints. π={vself 7→poor,vdest7→n}

wherepoor andn are defined as follows:

♦(·) poor n

Cons 0 0

List 0 0

Nil 0 0

Main 0 0

Conspoor Consn Aget(·,next) poor n Aset(·,next) poor poor

(3.1.2)

We say in this case that poor can be split into poor, poor and n, written

Circular lists

As a final example, we wish to show how our system prevents cyclic lists from being copied. If this was allowed, the program would not terminate and would require infinite amount of memory. Assume the following main method that creates a list with a loop and copies it.

Li st ma in () {

let co ns = new C ons in

let _ = c ons . nex t <- con s in r e t u r n con s . co py () ;

}

Letvcons be the view variable corresponding tocons, then we obtain the

constraint ♦(Consvcons_)≥♦(Consvres_{) + 1 by substituting the variable v}

self in

the constraints from the copy method with the variable vcons. Notice that

this requires the potential of Cons under vcons to be at least 1.

Further, handling aliasing gives us the constraint vcons vvcons⊕vcons⊕

vcons, making the system of constraints unsolvable since, on the one hand,

♦(Consvcons_{)≥1 and on the other hand,♦(Cons}vcons_{)≥3♦(Cons}vcons_).1

Notice that this is again a consequence of our rule for aliasing that guar- antees soundness at all times.