2.3 Semantics of FJEU
2.3.2 Special semantics for heap-space analysis
In Fig. 2.5 we define special operational semantics for FJEU programs which consists of adding counters (non-negative natural numbersmandm0) to the standard rules for keeping track of the number of unused heap units before and after evaluatingerespectively. We will use this semantics in Chapter 3, where we define a type system for the static prediction of the heap-space requirements of FJEU programs. Similar counters can be introduced for keeping track of the usage of other kind of resources.
Note that rule (`Sh N ew) is only applicable if there are enough un-
used heap units available for the allocation of a new object, otherwise the evaluation of a (`ShN ew) expression gets stuck. We require 1 heap unit
to allocate any object for simplicity. Practical implementations would take into account the size of the object and how many memory cells are needed for its allocation in the heap. Heap units are unconditionally made available again by thefreeexpression. Our analysis will identify an upper bound on mand a lower bound on m0 for a given expression and program.
We include the rule (`ShW aste) which allows us to abandon unused
memory units in order to facilitate some proofs.
Lemma 2.3.11 Let e be an expression. σ, τ be heaps and η be a stack. Then: ∃m, m0.D::η, σ mm0 e;v, τ iff E ::η, σ `e;v, τ.
Proof.
Case “⇒” By induction on the derivation D.
Case “⇐” By induction on the derivation E.
Operational Semantics of FJEU for heap-space analysis η, σ mm0 e;v, τ η, σ mm x;ηx, σ (`ShV ar) η, σ mm null;0, σ ( `ShN ull) ` /∈dom(σ) A(C) ={a1, . . . , ak} τ=σ[`7→(C, a1:0, . . . , ak:0)] η, σ mm+ 1 newC;`, τ ( `ShN ew) ηx=` σ`= (C, a1:v1, . . . , ak:vk) η, σ mm+ 1 free(x);0, σ[`7→(invalid)] (`Sh F ree) η, σ m m0+d e;v, τ η, σ mm0 e;v, τ (`Sh W aste) ηx=` σ`= (D, a1:v1, . . . , ak:vk) D <:C η, σ mm (C)x;ηx, σ (`ShCastI) ηx=0 η, σ mm (C)x;ηx, σ (`ShCastII) ηx=` σ`= (C, a1:v1, . . . , ak:vk) η, σ mm x.ai;vi, σ (`ShAccess) ηx=` σ`= (C0, a1:v1, . . . , ak:vk)a=ai τ =σ[`.ai7→ηy] η, σ mm x.a<-y;`, τ (`ShU pdate) η, σ mm0 e1;v1, ρ η[x7→v1], ρ m 0 m00 e2;v2, τ η, σ mm00 letx=e1ine2;v2, τ (`ShLet) ηx=` σ`= (C, a1:v1, . . . , ak:vk) Mbody(C, m) =e0 [this7→`, x17→ηy1, . . . , xj7→ηyj], σ m m0 e0;v, τ (`ShInv) η, σ mm0 x.m(~y);v, τ ηx=` σ(`) = (D, a1:v1, . . . , ak:vk) D <:E η, σ m m0 e1;v, τ
η, σ mm0 ifxinstanceofE thene1 elsee2;v, τ
(`ShCondI)
ηx=` σ(`) = (D, a1:v1, . . . , ak:vk) D<6 :E η, σ
m
m0 e2 ;v, τ
η, σ mm0 ifxinstanceofE thene1 elsee2;v, τ
(`ShCondII)
ηx=0 η, σ
m
m0 e2;v, τ
η, σ mm0 ifxinstanceofE thene1 elsee2;v, τ (
`ShCond III)
Lemma 2.3.12 (Waste)
1. ∀d∈N.D::η, σ mm0 e;v, τ =⇒ η, σ dd++mm0 e;v, τ.
2. Let D::η, σ mm0 e;v, τ. Then, if n≥m alsoη, σ nm0 e;v, τ.
Proof.
1. By induction on the derivationD.
2. We haven=m+x for somex. By item 1. we have η, σ m0n+x e;
v, τ, and by rule (`ShW aste) we getη, σ n
m0 e;v, τ.
2
It is convenient to extend the special semantics to real annotations so that these annotations can be found by solving linear arithmetic constraints.
Definition 2.3.13 We extend the operational semantics to real annotations
t, t0∈R+
0 in the following way:
η, σ tt0 e;v, τ ⇐⇒def η, σ
dte
dt0e e;v, τ
In the following chapters we shall study the problems of describing the an- notations using refined types and finding them automatically via type infer- ence.
Chapter 3
Resource Aware Java
In this chapter we extend the typing system of FJEU to a system of refined types called Resource Aware JAva (RAJA) for the compile-time analysis of the heap-space requirements of FJEU programs.
Recall that we assume a simple freelist based model where we maintain a set of free memory units, the freelist. When creating an object, a heap unit required to store it is taken from the freelist, provided it contains enough units. When deallocating an object, the unit returns to the freelist.
The goal of the analysis is to predict a bound on the initial size that the freelist must have so that a given program may be executed without causing unsuccessful abortion due to insufficient memory. We achieve this by combining amortised analysis [Tar85, Oka98] with type-based techniques in order to define potentials.
Essentially each object is ascribed an abstracted portion of the freelist, referred to as potential, which is just a nonnegative number, denoting the size of freelist portion associated with the object. Any object creation must be paid for from the potential in scope. The initial potential thus represents an upper bound on the total heap consumption.
In this chapter we shall describe the typing system RAJA. In Section 3.1 we describe the system informally and show its use in some examples. Sec- tion 3.2 then introduces the typing system formally. In Section 3.3 we de- scribe how to calculate a potential function based on the RAJA typing and prove the soundness of the system. Finally, Section 3.4 describes the prob- lems of type checking and type inference that we will attempt to solve in the following chapters.
3.1
Informal presentation and examples
Before we describe the RAJA system, we would like to demonstrate the front end of our method with a couple of small examples. In Fig. 3.1 we define singly linked lists using the Composite pattern.
c l a s s Li st { Li st co py () { r e t u r n nul l; } } c l a s s Nil e x t e n d s Lis t { Li st co py () { r e t u r n new Nil ; } } c l a s s Co ns e x t e n d s L ist { O b j e c t ele m ; Li st ne xt ; 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 ; } } c l a s s Ma in { Li st ma in ( Li st l ) { r e t u r n l . cop y () ; } }
Figure 3.1: Copying lists in FJEU.
We define the classListas an abstract list, the class Cons for describing the nodes and the class Nil for modelling the end of the list. Moreover, we define a method for copying lists. Running the analysis on the program yields the following results; no annotations by the programmer are required.
Program will execute successfully with a free-list >=
1. + 1. * length of the input
It is clear that the heap-space consumption of this program is exactly the length of the list plus 1, since during the execution of the program one Cons object for each node of the list is allocated and additionally one Nilnode is allocated.
Now let us consider a method for appending lists (Fig. 3.2). The call
sult into dest.next. The auxiliary object destis subsequently deallocated and the concatenated list is returned. When we analyse the program we obtain the following output:
Program will execute successfully with a free-list >= 1.
c l a s s Li st {
Co ns a p p A u x ( Li st y , Co ns de st ) { r e t u r n nul l;
}
Li st a p p e n d ( Li st y ) { let de st = new C ons in
let _ = thi s. a p p A u x ( y , des t ) in let r e s u l t = des t . nex t in
let _ = fre e ( des t ) in r e t u r n r e s u l t ; } } c l a s s Nil e x t e n d s Lis t { Co ns a p p A u x ( Li st y , Co ns de st ) { r e t u r n des t . ne xt <- y ; } } c l a s s Co ns e x t e n d s L ist { O b j e c t ele m ; Li st ne xt ; 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) ; } } c l a s s Ma in { Li st ma in ( Li st l1 , Lis t l2 ) { r e t u r n l1 . a p p e n d ( l2 ) ; } }
Figure 3.2: Appending lists in FJEU.
Notice that the heap-space consumption of the program is indeed constant since the list is appended in place and the only allocated object isdest. This example offers challenges to the analysis nevertheless, due to the aliasing
caused by the multiple use of the variable this in the method appAux in the class Cons. Later we will show how this example can be typed in our system.