Rarely Copying Garbage Collection

Rarely Copying Garbage Collection

Yoshinori Kobayashi,Toshio Endo,Kenjiro Taura, Akinori Yonezawa

University of Tokyo

PLDI 2002 Student Research Forum17,June, Berlin

Contents

• Design Goals

• Mark&Sweep v.s. Copying Collector

• Conservative Garbage Collector

• Bartlett's Mostly Copying Collector

• Rarely-Copying Collector

• Experiments and Discussion

Design Goals• Design Goals

– Fast Allocation– Conservative GC– Fast GC

• To achieve fast GC,it use hybrid strategy(Mark&Sweep,Copying)

• Target– Allocation intensive programs– Programs written in a type accurate language and

partially written in C language

Fast Allocation

void* allocate(size_t size){

prev = free;

free = free + size;

if(free < limit){

return prev;

}else{ ・・・ }

}

free

limit

Allocation request

size

Linear Allocation

There must be a large continuous free area

cf. Allocation From Freelist

• Allocator must search a sufficient area for an allocation request from freelist.

From_space To_space From_space

Copying GC makes a large continuous area

Mark&Sweep GC causes fragmentation

Performance tradeoff between Mark&Sweep and Copying

Allocation Garbage Collection

Mark & Sweep Freelist (Slower) Faster

Copying GC Linear Allocation (Faster) Slower

It strongly depends on the amount of live objects.

General tendency

cost of mark&sweep GC

cost of copy GC

2

M

Cost of GC and Allocation

Copy GC is better Mark-Sweep is better

L(live objects)

Performance tradeoff

Conservative Garbage Collector

Ambiguous pointer A word that Garbage Collector doesn’t know

whether it is a pointer or not. It appears in a program written in C language.

• The conservative collector considers objects pointed to by ambiguous pointers live.

• The collector cannot update ambiguous pointers– We cannot copy objects pointed to by ambiguous

pointers

Why Conservative GC?

Our GC's target

Programs written in type accurate language,partially written in C language

Developing programs in a given language very often requires programmers to integrate libraries written in other languages.

Programmers don’t like complex native interface.

A simple interface below needs Ambiguous Pointers.

int X_sum_Array(int* body){

(some work using body)

・・・

}

○ Simple Native Interface

× Fully Type-Accurate GC is impossible

Which interface would you like to use?

Another approach – Permit the existence of

　　　　　　　“ Ambiguous Pointers”

An example : JNI

JNIEXPORT jint JNICALL

Java_Foo_sumArray(JNIEnv* env,jobject* obj,jintArray arr){

jint* body = (*env)->GetIntArrayElements(env,arr,0);

(some work using body)

(*env)->ReleaseIntArrayelements(env,arr,body,0);

・・・

}

○ Fully Type-Accurate GC

×Complex Native Interface

One approach – Prohibit the existence of 　“ Ambiguous Pointers”

Another approach – Permit the existence of

　　　　　　　“ Ambiguous Pointers”

int X_sum_Array(int* body){

(some work using body)

・・・

}

○ Simple Native Interface

× Fully Type-Accurate GC is impossible

Which interface would you like to use?

Existing Work : Mostly-Copying Collector (Copy GC + Conservative

GC)Copying Garbage Collector in the presence of ambiguous

pointers

The root set consists of ambiguous pointers

There is no ambiguous pointer in the heap

The whole heap consists of fixed size blocks (pages)

The pages pointed to by ambiguous pointers : Mark & Sweep

The pages pointed to only by exact pointers : Copying GC

Root set

live

dead

Mostly-Copying Collector

Mostly-Copying collector

It copies live objects regardless of the amount of live objects.

It copies too many objects. GC is too expensive.

Why Rarely Copying Collector?(1) Mostly-Copying collector

Why Rarely Copying Collector?(2) Our approach

Our approach:

The whole heap consists of fixed size blocks(pages).

Mark & Selective Copy

Mark phase : it takes statistics.

It chooses better strategy for each page

Copying - pages the amount of live objects is small

Sweep - pages the amount of live objects is large

Our focus is making the total performance better than a collector with a single strategy.

Mark&Copy or Mark&Sweep for each page

Rcgc() {

Mark_with_profiling();

Sweep(pages_to_sweep);

Copy(pages_to_copy);

}

Profiling: for each page,keeping track of

The size of live objects in each page

the pointers which point to objects inside the page

Rarely-Copying Collector

Copy or Sweep? ～ for each page～

Is an object in the page pointed to by ambiguous pointers?

amount of live objects > Lth

# of Pointers > Pth

sweepcopy

Yes

Yes

No

No Lth, Pth:

the thresholds given by the user

Experiments

We will measure the costs of

Allocation

Garbage collection

changing the thresholds.

The experiments are now in progress.

The preliminary results will be available in a month.

Expected performance

Mark-Sweep

Copy GC

GC time Allocation time

Rarely-Copying

Mark Sweep Copy

Profiling overhead

Discussion

• Preliminary results show that

this technique reduces ..... by ** % and improves program performance by ??? % over Boehm's collector.

Summary

• We are implementing Rarely-Copying GC– Fast Allocation– Conservative Collector– Select Copy or Sweep

• Experiments are still in progress.

• Preliminary results will be available in a month.

ENDE