הטכניון – מכון טכנולוגי לישראל סמסטר אביב 2015 הפקולטה למדעי המחשב אלגוריתמים לניהול זיכרון דינמי – 236780 תרגיל בית 1 להגשה עד יום ג' 19/5/2015ב 12:00-בצהריים בתא הגשת התרגילים של המקצוע בקומה 1 .1תארו תוכנית שתגרום ל lazy sweep-להתנהג כמו sweepרגיל .כלומר ,למרות שה collector-מנסה לבצע את ה sweep-צעד אחר צעד ,התוכנית תמיד תכריח אותו לבצע את כל ה sweep-בבת אחת . הערות: א .על התוכנית להצליח להקצות כל בקשה ,כלומר היא אינה "עפה" בגלל מחסור בזיכרון. ב .הפיתרון הטריביאלי של להקצות ולשחרר רק אובייקט אחד בכל מחזור איסוף אינו מתקבל .יש לאפשר ל sweep-לשחרר לפחות 100אובייקטים בזמן האיסוף. .2שאלה זו מתייחסת ל:Generational Garbage Collection - א .בעת הרצת write barrierשל card markingהניחו שמבצעים רק חישוב הכתובת של הביט המתאים ל card-ומדליקים אותו )ללא שום בדיקות נוספות( .שימו לב שפלטפורמות מודרניות לא מרשות לכתוב ביט לזיכרון אלא לכל הפחות בית שלם. הדבר גורם לכך שכאשר מריצים write barrierכזה על מחשב רב-מעבדים צריך לבצע פעולת סנכרון בין ה mutators-בתוך ה.write barrier- .aהסבירו למה דרוש סנכרון. .bהציעו שיטה למנוע לחלוטין את הסנכרון ע"י הגדלת התקורה במקום .מה העלות במקום של השיטה שהצעתם? שימו לב שפעולה אטומית מפורשת מהסוג של compare & swapנחשבת פעולת סנכרון. .cהציעו שיטה למנוע רק חלק מפעולות הסנכרון אבל ללא תקורה במקום. )החלק של הפעולות שלא ידרוש סנכרון יכול להיות תלוי באפליקציה, בהיסטוריה של הריצה וכו'( מה עלות השיטה )בזמן( ואילו מפעולות הסנכרון היא חוסכת? ב. נציע עתה שינוי ל .Generational Garbage Collection-בשיטה החדשה ,לעולם לא נאסוף את הדור הצעיר לחוד .כל איסוף קורה כשאין יותר מקום להקצאה ואז אוספים גם את הדור הצעיר וגם את הדור המבוגר .אבל ,כל דור נאסף בשיטה המתאימה .הדור הזקן נאסף באמצעות mark and sweepוהדור הצעיר נאסף באמצעות .copyingעליכם לציין יתרון אחד וחיסרון אחד של )מימוש יעיל של( השיטה על פני generational garbage collectionרגיל המשתמש ב copying-לדור הצעיר וב mark and sweep-לדור המבוגר . .3השאלה מתייחסת ל:Train Algorithm- א .מה יקרה אם נשנה את האלגוריתם באופן הבא :כשמתחילים איסוף של רכבת, יוצרים רכבת Tחדשה )שמספרה גבוה מכל הרכבות הקיימות( .כל אובייקט שעבורו יש פוינטר כלשהו מחוץ לקרון הנאסף כרגע מועתק אל קרון ברכבת .T כשנגמר המקום בקרון שאליו מעתיקים ברכבת ,Tפותחים קרון חדש ומתחילים להעתיק אליו. .aהאם כל המעגלים ייאספו גם לאחר השינוי? אם כן – הסבר כיצד .אם לא – הסבר מדוע לא. .bהאם תמיד יהיה ניתן לאסוף רכיב קשיר לא נגיש שכולו בתוך הרכבת הנוכחית? .cכיצד תשתנה תשובתכם ל b-אם נוציא לרכבת Tרק אובייקטים המוצבעים מחוץ לרכבת הנוכחית? ב .כזכור ,באלגוריתם המקורי נמצא באג הנובע מכך שהמצביעים משתנים ע"י התוכנית בין איסוף קרון אחד למשנהו .נציע תיקון שונה מזה שהוצג ע"י Seligman- .Grarupעליכם לומר אם גם תיקון זה עובד כשורה )ולנמק( או להציע דוגמה נגדית המוכיחה שאלגוריתם זה לא מתקן את הבאג . התיקון :בעת ריצת התוכנית יש write barrierהמעדכן את ה .remembered set-נוסיף ל write barrier-בדיקה :אם השינוי של המצביע הנוכחי מבטל הצבעה אל אובייקט Aהנמצא ברכבת הנוכחית שאנו אוספים ,אז נסמן את האובייקט Aכאובייקט מיוחד .בעת איסוף הקרון ,נעתיק את כל האובייקטים המיוחדים אל הרכבת האחרונה ונוציא אותם מרשימת המיוחדים . בתשובתכם הפרידו בין שני מקרים :מקרה בו ה write-barrier-עובד גם על ה,roots- ומקרה בו ה write-barrier-לא פועל על ה.roots- ג .בהינתן שהרכבת התחתונה מכילה nקרונות ובכל קרון יש mאובייקטים תוך כמה איסופים מובטח שרכבת זו תתרוקן או תיאסף? תארו את המקרה הגרוע ביותר שיגרום למספר איסופים מקסימאלי לפני ריקון הרכבת לכל mו n-נתונים. .aהסבירו כמה איסופים צריך עבור הדוגמא שלכם. .bהוכיחו שזה המקרה הגרוע ביותר .כלומר ,לא ניתן להציג מקרה יותר גרוע .4שאלה זו מתייחסת לאלגוריתם ה compaction-של :Jonkers א .כזכור האלגוריתם משתמש בשרשור על-מנת לעדכן את המצביעים להצביע למקום החדש של האובייקט .הסבירו מהי פעולת השרשור וכיצד משתמשים בה. ב .הסבירו כיצד ניתן לשלב את השרשור של השלב הראשון של האלגוריתם של Jonkersעם ה trace-של האובייקטים בזמן ה .mark-מה נותר לביצוע בפאזה הראשונה של האלגוריתם המעודכן? ומה בפאזה השנייה? ג .האם ניתן להעביר יותר פעילות של הדחיסה לתוך ה) trace-ללא ביצוע heap passנוסף וללא שימוש בזיכרון נוסף( ואז לוותר על הפאזה הראשונה כולה? ד .כיצד ייקבע סדר האובייקטים בשרשרת של אובייקט כאשר יורץ האלגוריתם שתכננתם בסעיף ב'? ה .האם ניתן לבצע את כל השרשורים בזמן ה trace-בשיטה דומה לסעיף ב' ואז לוותר על הפאזה הראשונה לחלוטין ולבצע מיד את הפאזה השנייה? אם כן – הסבירו כיצד .אם לא – נמקו. ו .כיצד ישפיע השינוי של סעיף ב' על ה locality-של אלגוריתם הדחיסה? התייחסו רק לשינוי שנגרם ע"י הכנסת השרשור של החלק הראשון אל תוך הtrace- והוצאתו משלב המעבר הראשון .האם אתם מצפים לשיפור ב ?locality-הסבירו . הניחו שבניהם של אובייקטים נמצאים במקום אקראי כלשהו בזיכרון )ולאו דווקא ליד האובייקטים ההורים(. .5נניח שהיה ניתן לקבל ממערכת ההפעלה מידע על "מצביעים הפוכים" .כלומר ,לכל אובייקט היה ניתן לקבל )באופן פלאי( ביעילות רשימה של כל אבותיו ע"י הפעלת קריאת מערכת " "parents-getעם כתובת האובייקט) .רשימת האבות כוללת גם אבות שהם שורשים (.בשאלה זו נבדוק כיצד היה ניתן להשתמש בפעולה זו לאיסוף אשפה. כשנאמר "נגיש"" ,אבות" ,ו"בנים" נתכוון למושגים האלה ביחס למצביעים המקוריים )ולא ההפוכים( . ניתן להניח שהרוטינה parents-getמתבצעת באופן אטומי והיא מודעת תמיד למצב הנוכחי של ה heap-על כל ההזזות שאובייקטים עברו עד נקודת הזמן שבו היא נקראה. א .האם בעזרת המידע על המצביעים ההפוכים בלבד ניתן לדעת עבור אובייקט נתון כלשהו אם הוא נגיש מהשורשים או לא )מבלי להתבונן במכוונים ה"רגילים" שבתוך האובייקט(? נמקו. ב .במידה וגילינו שאובייקט אינו נגיש )מהשורשים( .האם מובטח שגם כל בניו לא נגישים? האם מובטח שגם כל אבותיו לא נגישים? ג .תארו אלגוריתם יעיל ככל האפשר ל compaction-בסביבה זו המשתמש במעבר אחד בלבד על ה) heap-בהינתן סימון מי מהאובייקטים חי ומי מת( .הסבירו את מחיר האלגוריתם בזמן ומקום. ד .נניח שכל תוכניות המחשב בג'אווה בעולם אינן מכוונות יותר משני מצביעים אל אותו אובייקט) .כלומר לכל אובייקט יש לכל היותר 2אבות( .תארו מימוש )יעיל ככל יכולתכם( של .parent-getניתן כמובן להשתמש ב barrier-read-או ב ,barrier-write-בנוסף אולי לביצוע פעולות נוספות בזמן ה.compaction- הסבירו את העלויות במקום וזמן. ה .עתה נניח שבתוכניות ג'אווה ל 98%-מהאובייקטים יש לכל היותר שני אבות, אבל לשאר האובייקטים ייתכנו יותר אבות ,אך לכל היותר .10התוכלו לתאר מימוש )יעיל ככל האפשר( של parent-getהמסוגל לטפל גם ב2%- האובייקטים הפופולאריים? ו .נניח שמנסים למקבל את האלגוריתם שהצעתם בסעיף ג' ע"י חלוקת הheap- לאזורים .כל חוט מבקש אחריות על אזור )באופן מסונכרן( ואז מבצע compactionלוקלי באזור תוך הזזת האובייקטים בתוך האזור לתחילתו .האם ייתכן raceבין חוטי ה compaction-באלגוריתם .
© Copyright 2024