Paul R. Wilson & Mark S. Johnstone University of Austine Texas 1993 Real Time Non-Copying GC מוגש ע ” י רם נתנאל

הקדמה עד היום לא שולב בהצלחה Garbage Collection במערכות Real Time. הדבר גרם לכך ששפות שמשתמשות ב GC לא חדרו לתחומים רבים בהם שילוב בתוך חומרה ומערכות הפעלה ובקרה של מכשירים.

דרישות מ GC בסביבת RT n הבטחת יחס ביצועים קבוע לכל התכנית n הבטחת יחס ביצועים קבוע באופן נקודתי בתכנית n OverHead קטן ככל האפשר

תנאים הכרחיים GC שפועל בסביבת RT חייב להיות אינקרימנטלי – מסוגל לבצע פעולות קטנות בזמן ריצתה של התכנית במקום לעצור את התכנית לזמן ארוך בכל פעם. ( הבטחת יחס ביצועים לטווח קצר ) לא מספיק למצוא חסם על אורך פעולות העדכון, צריך למצוא חסם על התדירות שבה יש עדכונים. ( הבטחת יחס ביצועים גלובלית ) בכל זמן שהוא מוקצה אחוז מסוים מפעולת ה CPU לטובת התכנית. ( הבטחת יחס ביצועים נקודתית )

מסקנה לכן עדיף שה Collector יהיה תכנית שרצה במקביל ל Mutator ואוספת זיכרון מבלי להפריע לריצה השוטפת של ה Mutator.

Write Barrier לעומת Read Barrier Read Barrier בכל פעם שה Mutator ניגש לקריאה של פוינטר יתבצע קוד נוסף שידאג לכך שהמידע שה Mutator עומד לקרוא הוא עדכני. למשל להפנות את ה Mutator למקום אחר. Write Barrier בכל פעם שה Mutator מנסה לשנות את אחד הפוינטרים בתכנית, יתבצע קוד נוסף שידאג לכך שה Collector יודע על השנוי ונערך בהתאם.

Read Barrier בהפעלת Read Barrier יש בעצם סנכרון בין התמונה שרואה ה Mutator לבין פעולות ה Collector בכך שבכל פעם שמה שרואה ה Mutator אינו עקבי עם פעולות ה Collector ה Mutator ישנה את תמונת העולם שלו. ה Collector מבחינתו מתנהג בדיוק כמו שה Mutator נעצר לצורך ה GC.

Write Barrier בהפעלת Write Barrier ה Mutator הוא שקובע וה Collector מעדכן את תמונת העולם שלו לפי פעולות ה Mutator כך שיתכן שה Collector יאלץ לבצע יותר פעולות מאשר יהי מבצע אילו ש Mutator היה עוצר בזמן ה GC.

האחריות על הסנכרון חייבת להיות של ה Mutator כי לא ניתן לצפות את פעולותיו.

Read Barrier תכונות : n עלות גבוהה. n לא צפוי – יתכן שבפרוש ביטוי אחד יש שימוש בהרבה ערכי פוינטרים ולכן קשה לקבוע עלות ממוצעת של OverHead.

Write Barrier תכונות : n עלות נמוכה. n יותר צפוי – קיים יחס ביצועים טוב יותר גם ב Worst Case. לכן מתאים יותר לסביבת RT. n ה Mutator אינו תלוי בעבודה שעשה עד עכשיו ה Collector ולכן ה Collector לא יכול לעקב את התקדמות התכנית. Write Barrier מתאים יותר לאפליקציות Real Time כי לא ממש חשוב כמה עבודה יעשה ה Collector כל עוד אינו מפריע לפעולת ה Mutator.

אלגוריתם Baker האלגוריתם מבצע Copying Garbage Collection בצורה אינקרימנטלית. ה Mutator וה Collector מדברים ביניהם ע " י העברת הודעות באופן שוטף. יש שימוש ב Read Barrier לשם שמירה על עקביות של מה שרואה ה Mutator לעומת גרף האובייקטים.

בעיות : העברת מידע בין ה Mutator וה Collector היא בעקרון בעיה במערכות RT כי קיימת הפרעה לריצת התכנית. אם ה MailBox נבדקת בתדירות מסוימת ע " י ה Mutator העלות גדולה. אם משתמשים ב Interrupt יש הפרעה לריצת ה Mutator שעלולה להגיע ברגעים קריטיים. יש שימוש ב Read Barrier אשר אמנם כל עדכון בו נעדה מהר יחסית אבל יתכן שעדכונים נעשים בתדירות גבוהה וגורמים לתכנית לא להספיק למועד הסיום.

לדוגמא : ריצה על רשימה מקושרת for i=1 to list.size p=p.next end אם הרשימה עדיין לא הועתקה ע ” י ה Collector היא תועתק איבר איבר בגלל ה Read Barrier. אמנם העתקת איבר היא לא ארוכה אבל סך כל העבודה המצטברת תגרום לכך שהתכנית לא תסיים הזמן.

תגובת האלגוריתם : בכל צעד ה Mutator יורה ל Collector להביא את האיבר הבא ברשימה. למרות שביצוע כל צעד לוקח זמן קטן לאורך כל הרימה של התכנית ה Collector יעקב מאד את התכנית ויתכן שלא נעמוד ב deadline.

הרחבות : קיימים אלגוריתמים שניסו לשפר את האלגוריתם של Baker ע " י פעולות ברמה של Page שלם ואיטרציות יותר גדולות ופחות תכופות. התוצאה היא שהתנהגות התכנית עוד פחות ניתנת לצפייה מראש.

הגישה לפתרון אנחנו לא נבטיח שבכל מסלול אפשרי בתכנית תמיד סך העבודה לא יצטבר ליותר מאשר חסם קבוע, אבל ננסה להבטיח שהעדכונים לא יקרו בתדירות גבוהה מידי. הבטחה כזו דורשת קשר פחות הדוק בין ה Mutator לבין ה Collector. נשתמש ב Write Barrier בלבד, ב Garbage Collection שאינו מבצע Copying.

יישום ניתן לצבוע את האובייקטים בשלושה צבעים : שחור – אובייקט אשר סרקנו אותו ואת כל הבנים שלו. אפור – אובייקט אשר הגענו אליו בסריקה אבל לא בהכרח עברנו על כל שכניו. לבן – אובייקט שעדיין לא נסרק. אנו צריכים לגרום לכך שבכל עדכון של פוינטרים ע " י ה Mutator לא נגיע למצב שבו אובייקט שחור מצביע על אובייקט לבן. אחרת יתכן וזה המצביע היחידי אל האובייקט הלבן ואז יישאר Dangling Pointer

לדוגמא : מתחיל במצב חוקי : כל האובייקטים הלבנים נגישים

לדוגמא : עדיין מצב חוקי

לדוגמא : קיים אובייקט אשר לא יסרק לעולם

דרכים לפתרון n SnapShot at beginning – אף פוינטר לא יעלם. בכל פעם שפוינטר ישנה ערך ניצור משתנה דמי שיצביע על הערך הישן. n Incremental Update – בכל פעם שישתנה פוינטר שנמצא באובייקט שחור נודיע על כך ל Collector כדי שיסרוק את האובייקט החדש או ישנה את הצבע לאפור.

SnapShot-at-Beginning השיטה מבטיחה : בכל פעם שנשבר מסלול לאובייקט נוצר מסלול חדש לאובייקט. לכן לא יתכן שקיים אובייקט אשר ה Mutator יכול להגיע אליו אך ה Collector לא.

בעיות אופטימיזציה : n קשה לבנות טיפול שונה במשתנים על המחסנית n לא ניתן להשתמש במידע על Liveness של משתנים. n קשה לשילוב עם טכניקות של Generational ו hierarchical Garbage Collection. n גם אם המתכנת שיחרר את הזיכרון קשה להשתמש במידע הזה.

Incremental Update שומר על התכונה המקומית שלא יווצר מצב שבו יש פוינטר מאובייקט שחור לאובייקט לבן. אם ה Mutator יוצר פוינטר כזה אז נודיע על כך ל Collector כדי שיהפוך אחד מהם לאפור.

יתרונות אופטימיזציה n פחות קונסרבטיבי - שנוי של פוינטר מאובייקט לבן לא מפריע. n לא ניגע במחסנית עד סוף הסריקה - עוזר להפטר מהרבה Floating Garbage. n קל יותר להסבה ל Generational GC. n ניתן לשלב מידע מהמתכנת ( כגון שחרור זכרון )

ניקוי הזכרון לא נרצה לבצע Copying מלא. לכן נשמור את האובייקטים בתוך רשימות מקושרות דו - כיווניות ושינוי צבע של אובייקט או שחרורו יהיה העברתו מרשימה לרשימה. נקצה אובייקטים רק בגדלים שהם חזקות של 2 ובכך נקווה למנוע פרגמנטציה.

יתרונות : אין העתקה ממשית של אובייקטים לכן המחיר של יישום האלגוריתם קטן בהרבה. מכיוון שהאובייקטים לא זזים במהלך התכנית לא מבלבלים את ה Mutator.

חסרונות : תתכן פרגמנטציה גדולה מאד של הזיכרון. במקרה הגרוע ביותר : אם בכל איטרציה נקצה זיכרון בגודל אחר עד שנגמר ואז נשחרר הכל, נקצה לכל אובייקט זיכרון מחדש. למעשה במקרה הממוצע העלות הייתה סבירה.

ישום האלגוריתם יושם בשפת ++C ע ” י Operator Overloading ונבחן על מספר תכניות. זמני ריצה הראו פגיעה של % 10-90, כנראה בגלל חוסר תמיכה מהקומפיילר.

לסיכום : ראינו Garbage Collector שפועל בסביבת Real Time, ניתן לשילוב במספר טכניקות של GC, ומסוגל בפועל להבטיח יחס ביצועים קבוע לאורך ריצת התכנית. האלגוריתם כולל Write Barrier בלבד ולכן הוא יחסית זול למימוש, ואינו דורש חומרה מיוחדת או תמיכה מיוחדת ממערכת ההפעלה.

תכניות לעתיד n להפעיל בצורה מבוזרת n לשלב Generational GC n להפעיל מספר Collectors בו זמנית. n לשכלל את ניהול הזכרון להתמודד עם פרגמנטציה.