rarely copying garbage collection
DESCRIPTION
Rarely Copying Garbage Collection. Yoshinori Kobayashi,Toshio Endo,Kenjiro Taura, Akinori Yonezawa University of Tokyo PLDI 2002 Student Research Forum 17,June, Berlin. Contents. Design Goals Mark&Sweep v.s. Copying Collector Conservative Garbage Collector - PowerPoint PPT PresentationTRANSCRIPT
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