השגיאה המתמטית היא שאתה כולל את השטח שמכיל את הוקטור הקיים, השטח שעדיין
לא שוחרר, כחלק מהזיכרון החדש שאתה יכול להקצות. זה פשוט חישוב לא נכון. אם מקצים
תחילה [tex]t[/tex] מקום, ומכפילים כל פעם בקבוע [tex]k[/tex], אז בפעם השנייה יש לנו [tex]kt[/tex], בפעם השלישית
[tex]k^2t[/tex], ובאופן כללי בפעם ה-[tex]n[/tex] יש לנו [tex]k^{n-1}t[/tex].

ההקצאה השלישית לא יכולה להשתמש במקום של ההקצאה השנייה, כי הוא בשימוש כרגע,
ולכן יכולה להשתמש רק בזה של הראשונה. ההקצאה השלישית גם תשתמש במקום חדש.
עכשיו ההקצאה הרביעית יכולה להשתמש במקום של ההקצאה השנייה והראשונה (אבל לא
של השלישית, כי היא בשימוש כרגע). זה אומר שאנחנו רוצים שהקבוע [tex]t[/tex] יהיה כזה שסכום
שתי ההקצאות הראשונות יהיה שווה לרביעית: [tex]t+kt=k^3t[/tex], שהופך ל-[tex]1+k=k^3[/tex].

הפיתרון הממשי של המשוואה הזו לפי מחשבון אינטרנט אקראי שמצאתי בגוגל הוא:
[tex]k=1.3247179572447458[/tex]. אמנם לא מדובר בקבוע מפורסם כלשהו, בניגוד ל-[tex]\phi[/tex],
אבל זה הפיתרון הנכון.

עכשיו, ביצענו את ההקצאה הרביעית שתפסה את המקום של הראשונה והשנייה, ושחררנו
את ההקצאה השלישית. ביצענו הקצאה חמישית ושיחררנו את הרביעית. ההקצאה השישית
לא יכולה להשתמש בזו של החמישית (כי היא בשימוש כרגע), והשטח של ההקצאה הרביעית
בלבד לא יספיק (הוא שווה לראשונה ולשניה, והשטח של השלישית בחלקו בשימוש על-ידי
החמישית). אז ביצענו גם הקצאה שישית. עכשיו אנחנו אולי רוצים שהשטח של ההקצאה
השביעית יהיה כזה שייכנס לזיכרון שבא לפני תחילת ההקצאה השישית. כלומר: ההקצאה
הרביעית והחמישית: [tex]k^6t=k^3t+k^4t[/tex], ה-[tex]t[/tex] כמובן מצטמצם כמו קודם, וגם רוב ה-[tex]k[/tex]-ים,
ומתקבלת המשוואה המוכרת מלמעלה: [tex]1+k=k^3[/tex]. זו התוצאה הכללית של מצב שבו אנחנו
רוצים שכל הקצאה תוכל להשתמש בזיכרון של שתי ההקצאות הישנות יותר מהשלוש שבאו
לפניה ([tex]k^nt+k^{n+1}t=k{n+3}t = 1+k=k^3[/tex]). אם אתה רוצה "למחזר זיכרון" בכל
פעם חמישית, או באיזושהי צורה אחרת, תקבל משוואה אחרת וקבוע אחר, כמובן. [tex]\phi[/tex] נכון רק
בשאיפה לאינסוף, ולכן חסר כל משמעות פרקטית. כמו שהראתי, כדי לנצל את הזיכרון מחדש
מהר ככל האפשר, צריך ערך של 1.35 בקירוב, ו-1.5 אינו מספיק.

זה התיקון למתמטיקה, וכעת נעבור לפרקטיקה:

[tex]\phi[/tex] הוא הערך הקריטי שבו בשאיפה לאינסוף נצליח לנצל מחדש זיכרון. 1.5 הוא ערך שבו
נצליח לנצל מחדש זיכרון קודם בשלב כלשהו. 2 בתור מספר שגבוה מהערך הקריטי הוא
קבוע הגדלה שאיתו לעולם לא נצליח לנצל מחדש זיכרון. אבל השאלה הפרקטית היא האם
מדובר בבעיה אמיתית, שבגללה שווה לנו לבצע כל-כך הרבה הקצאות והעתקות. אם התשובה
היא לא, אז במקרים מסויימים אולי נעדיף קבועים גדולים, כמו 10 לדוגמה (לדוגמה: אם אנחנו
יודעים שברגע שהוקטור עבר את הערך שקבענו לו עם reserve, זה אומר שהולך להיכנס אליו
עוד המון מידע), ולא אכפת לנו שהם עוברים את [tex]\phi[/tex].

התשובה היא שהיום באמת לא אכפת לנו. הטיעון בנוי משני חלקים:

ראשית, עלינו להבין (כמו שאגב אפשר לראות בקישור שהבאתי ובגוגל בכלל) שגם בטיעון
המקורי דובר על "בזבוז, מול "מחזור" של טווחי כתובות, ולא של זיכרון. אם ניקח את
פלטפורמת Intel x86 כמקרה-בוחן נבין למה כך נראה הטיעון: ממילא תמיד משתמשים
במנגנון ה-paging והזיכרון הפיזי ממוחזר בבלוקים של 4K. הבעיה היא רק בזבוז טווח
הכתובות שניתן לתוכנה.

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

שנית, היום, כשמקבלים טווחי כתובות גדולים מאוד שאט אט מתקדמים לכיוון ה-64 ביט,
אין בעיה פרקטית של "בזבוז" של טווחי כתובות. ווינדוס, לדוגמה, נותנת לתהליכי 64 ביט
8TB של זיכרון וירטואלי, מה שהרבה יותר גדול מהזיכרון הפיזי לרוב המחשבים שמריצים
קוד CPP שנכתב בעזרת VCPP, כך שהזיכרון הפיזי ייגמר הרבה לפני שייגמר טווח הכתובות,
ולכן אין טעם לבצע העתקות מיותרות כדי לפתור בעיה שלא נזכה להגיע אליה.