260 likes | 394 Views
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
E N D
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 • 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 Linear Allocation void* allocate(size_t size){ prev = free; free = free + size; if(free < limit){ return prev; }else{ ・・・ } } free size Allocation request limit There must be a large continuous free area
cf. Allocation From Freelist • Allocator must search a sufficient area for an allocation request from freelist.
Copying GC makes a large continuous area From_space From_space To_space
Performance tradeoff between Mark&Sweep and Copying General tendency • It strongly depends on the amount of live objects.
Cost of GC and Allocation cost of mark&sweep GC cost of copy GC L(live objects) Copy GC is better Mark-Sweep is better
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 pointerslive. • The collector cannot update ambiguous pointers • We cannot copy objects pointed to by ambiguous pointers
WhyConservative 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.
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?
Another approach – Permit the existence of “Ambiguous Pointers” One approach – Prohibit 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 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
Mostly-Copying Collector Root set live dead
Why Rarely Copying Collector?(1) 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?(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
Rarely-Copying Collector • 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
Copy or Sweep?~for each page~ Yes Is an object in the page pointed to by ambiguous pointers? No Yes amount of live objects > Lth # of Pointers > Pth Lth, Pth: the thresholds given by the user No copy sweep
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 GC time Allocation time Mark-Sweep Copy GC Profiling overhead Rarely-Copying Mark Sweep Copy
Discussion • Preliminary resultsshow 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.