Index: doc/theses/mubeen_zulfiqar_MMath/AllocDS1.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/AllocDS1.fig (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ (revision ) @@ -1,162 +1,0 @@ -#FIG 3.2 Produced by xfig version 3.2.7b -Landscape -Center -Inches -Letter -100.00 -Single --2 -1200 2 -6 4200 1575 4500 1725 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4275 1650 20 20 4275 1650 4295 1650 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4350 1650 20 20 4350 1650 4370 1650 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4425 1650 20 20 4425 1650 4445 1650 --6 -6 2850 2475 3150 2850 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2925 2475 2925 2700 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 2850 2700 3150 2700 3150 2850 2850 2850 2850 2700 --6 -6 4350 2475 4650 2850 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 4425 2475 4425 2700 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 4350 2700 4650 2700 4650 2850 4350 2850 4350 2700 --6 -6 3600 2475 3825 3150 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3675 2475 3675 2700 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3600 2700 3825 2700 3825 2850 3600 2850 3600 2700 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3600 3000 3825 3000 3825 3150 3600 3150 3600 3000 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3675 2775 3675 3000 --6 -6 4875 3600 5175 3750 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4950 3675 20 20 4950 3675 4970 3675 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5025 3675 20 20 5025 3675 5045 3675 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5100 3675 20 20 5100 3675 5120 3675 --6 -6 4875 2325 5175 2475 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4950 2400 20 20 4950 2400 4970 2400 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5025 2400 20 20 5025 2400 5045 2400 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5100 2400 20 20 5100 2400 5120 2400 --6 -6 5625 2325 5925 2475 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5700 2400 20 20 5700 2400 5720 2400 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5775 2400 20 20 5775 2400 5795 2400 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5850 2400 20 20 5850 2400 5870 2400 --6 -6 5625 3600 5925 3750 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5700 3675 20 20 5700 3675 5720 3675 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5775 3675 20 20 5775 3675 5795 3675 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5850 3675 20 20 5850 3675 5870 3675 --6 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2400 2100 2400 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2550 2100 2550 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2700 2100 2700 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2850 2100 2850 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3000 2100 3000 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3600 2100 3600 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3900 2100 3900 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4050 2100 4050 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4200 2100 4200 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4350 2100 4350 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4500 2100 4500 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3300 1500 3300 1800 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3600 1500 3600 1800 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3900 1500 3900 1800 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3000 1500 4800 1500 4800 1800 3000 1800 3000 1500 -2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3225 1650 2625 2100 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3150 1650 2550 2100 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3450 1650 4050 2100 -2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3375 1650 3975 2100 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2100 2100 2100 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 1950 2250 3150 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3450 2250 4650 2250 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 1950 2100 3150 2100 3150 2550 1950 2550 1950 2100 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3450 2100 4650 2100 4650 2550 3450 2550 3450 2100 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2250 2100 2250 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3750 2100 3750 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2025 2475 2025 2700 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2025 2775 2025 3000 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 1950 3000 2100 3000 2100 3150 1950 3150 1950 3000 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 1950 2700 2100 2700 2100 2850 1950 2850 1950 2700 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 - 1 1 1.00 45.00 90.00 - 1950 3750 2700 3750 2700 3525 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 1950 3525 3150 3525 3150 3900 1950 3900 1950 3525 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 - 1 1 1.00 45.00 90.00 - 3450 3750 4200 3750 4200 3525 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3450 3525 4650 3525 4650 3900 3450 3900 3450 3525 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 - 1 1 1.00 45.00 90.00 - 3150 4650 4200 4650 4200 4275 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3150 4275 4650 4275 4650 4875 3150 4875 3150 4275 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 1950 2400 3150 2400 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3450 2400 4650 2400 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5400 2100 5400 3900 -4 2 0 50 -1 0 11 0.0000 2 120 300 1875 2250 lock\001 -4 1 0 50 -1 0 12 0.0000 2 135 1935 3900 1425 N kernel-thread buckets\001 -4 1 0 50 -1 0 12 0.0000 2 195 810 4425 2025 heap$_2$\001 -4 1 0 50 -1 0 12 0.0000 2 195 810 2175 2025 heap$_1$\001 -4 2 0 50 -1 0 11 0.0000 2 120 270 1875 2400 size\001 -4 2 0 50 -1 0 11 0.0000 2 120 270 1875 2550 free\001 -4 1 0 50 -1 0 12 0.0000 2 180 825 2550 3450 local pool\001 -4 0 0 50 -1 0 12 0.0000 2 135 360 3525 3700 lock\001 -4 0 0 50 -1 0 12 0.0000 2 135 360 3225 4450 lock\001 -4 2 0 50 -1 0 12 0.0000 2 135 600 1875 3000 free list\001 -4 1 0 50 -1 0 12 0.0000 2 180 825 4050 3450 local pool\001 -4 1 0 50 -1 0 12 0.0000 2 180 1455 3900 4200 global pool (sbrk)\001 -4 0 0 50 -1 0 12 0.0000 2 135 360 2025 3700 lock\001 -4 1 0 50 -1 0 12 0.0000 2 180 720 6450 3150 free pool\001 -4 1 0 50 -1 0 12 0.0000 2 180 390 6450 2925 heap\001 Index: doc/theses/mubeen_zulfiqar_MMath/AllocDS2.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/AllocDS2.fig (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ (revision ) @@ -1,126 +1,0 @@ -#FIG 3.2 Produced by xfig version 3.2.7b -Landscape -Center -Inches -Letter -100.00 -Single --2 -1200 2 -6 2850 2100 3150 2250 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 2925 2175 20 20 2925 2175 2945 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3000 2175 20 20 3000 2175 3020 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3075 2175 20 20 3075 2175 3095 2175 --6 -6 4050 2100 4350 2250 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4125 2175 20 20 4125 2175 4145 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4200 2175 20 20 4200 2175 4220 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4275 2175 20 20 4275 2175 4295 2175 --6 -6 4650 2100 4950 2250 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4725 2175 20 20 4725 2175 4745 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4800 2175 20 20 4800 2175 4820 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4875 2175 20 20 4875 2175 4895 2175 --6 -6 3450 2100 3750 2250 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3525 2175 20 20 3525 2175 3545 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3600 2175 20 20 3600 2175 3620 2175 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3675 2175 20 20 3675 2175 3695 2175 --6 -6 3300 2175 3600 2550 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3375 2175 3375 2400 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3300 2400 3600 2400 3600 2550 3300 2550 3300 2400 --6 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3150 1800 3150 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2850 1800 2850 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4650 1800 4650 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4950 1800 4950 2250 -2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 4500 1725 4500 2250 -2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5100 1725 5100 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3450 1800 3450 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3750 1800 3750 2250 -2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3300 1725 3300 2250 -2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3900 1725 3900 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5250 1800 5250 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5400 1800 5400 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5550 1800 5550 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5700 1800 5700 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 5850 1800 5850 2250 -2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2700 1725 2700 2250 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3375 1275 3375 1575 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2700 1275 2700 1575 -2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2775 1275 2775 1575 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 5175 1275 5175 1575 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 5625 1275 5625 1575 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3750 1275 3750 1575 -2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 3825 1275 3825 1575 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2700 1950 6000 1950 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2700 2100 6000 2100 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 2700 1800 6000 1800 6000 2250 2700 2250 2700 1800 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2775 2175 2775 2400 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 2775 2475 2775 2700 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 2700 2700 2850 2700 2850 2850 2700 2850 2700 2700 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 2700 2400 2850 2400 2850 2550 2700 2550 2700 2400 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 4575 2175 4575 2400 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 4500 2400 5025 2400 5025 2550 4500 2550 4500 2400 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 - 1 1 1.00 45.00 90.00 - 3600 3525 4650 3525 4650 3150 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3600 3150 5100 3150 5100 3750 3600 3750 3600 3150 -4 2 0 50 -1 0 11 0.0000 2 120 300 2625 1950 lock\001 -4 1 0 50 -1 0 10 0.0000 2 150 1155 3000 1725 N$\\times$S$_1$\001 -4 1 0 50 -1 0 10 0.0000 2 150 1155 3600 1725 N$\\times$S$_2$\001 -4 1 0 50 -1 0 12 0.0000 2 180 390 4425 1500 heap\001 -4 2 0 50 -1 0 12 0.0000 2 135 1140 2550 1425 kernel threads\001 -4 2 0 50 -1 0 11 0.0000 2 120 270 2625 2100 size\001 -4 2 0 50 -1 0 11 0.0000 2 120 270 2625 2250 free\001 -4 2 0 50 -1 0 12 0.0000 2 135 600 2625 2700 free list\001 -4 0 0 50 -1 0 12 0.0000 2 135 360 3675 3325 lock\001 -4 1 0 50 -1 0 12 0.0000 2 180 1455 4350 3075 global pool (sbrk)\001 -4 1 0 50 -1 0 10 0.0000 2 150 1110 4800 1725 N$\\times$S$_t$\001 Index: doc/theses/mubeen_zulfiqar_MMath/Makefile =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/Makefile (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ doc/theses/mubeen_zulfiqar_MMath/Makefile (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -1,14 +1,15 @@ -DOC = uw-ethesis.pdf -BASE = ${DOC:%.pdf=%} # remove suffix # directory for latex clutter files -BUILD = build -TEXSRC = $(wildcard *.tex) -FIGSRC = $(wildcard *.fig) -BIBSRC = $(wildcard *.bib) -TEXLIB = .:../../LaTeXmacros:${BUILD}: # common latex macros -BIBLIB = .:../../bibliography # common citation repository +Build = build +Figures = figures +Pictures = pictures +TeXSRC = ${wildcard *.tex} +FigSRC = ${notdir ${wildcard ${Figures}/*.fig}} +PicSRC = ${notdir ${wildcard ${Pictures}/*.fig}} +BIBSRC = ${wildcard *.bib} +TeXLIB = .:../../LaTeXmacros:${Build}: # common latex macros +BibLIB = .:../../bibliography # common citation repository MAKEFLAGS = --no-print-directory # --silent -VPATH = ${BUILD} +VPATH = ${Build} ${Figures} ${Pictures} # extra search path for file names used in document ### Special Rules: @@ -18,38 +19,46 @@ ### Commands: -LATEX = TEXINPUTS=${TEXLIB} && export TEXINPUTS && latex -halt-on-error -output-directory=${BUILD} -BIBTEX = BIBINPUTS=${BIBLIB} bibtex -#GLOSSARY = INDEXSTYLE=${BUILD} makeglossaries-lite + +LaTeX = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex -halt-on-error -output-directory=${Build} +BibTeX = BIBINPUTS=${BibLIB} bibtex +#Glossary = INDEXSTYLE=${Build} makeglossaries-lite ### Rules and Recipes: +DOC = uw-ethesis.pdf +BASE = ${DOC:%.pdf=%} # remove suffix + all: ${DOC} -${BUILD}/%.dvi: ${TEXSRC} ${FIGSRC:%.fig=%.tex} ${BIBSRC} Makefile | ${BUILD} - ${LATEX} ${BASE} - ${BIBTEX} ${BUILD}/${BASE} - ${LATEX} ${BASE} -# ${GLOSSARY} ${BUILD}/${BASE} -# ${LATEX} ${BASE} +clean: + @rm -frv ${DOC} ${Build} -${BUILD}: +# File Dependencies # + +${Build}/%.dvi : ${TeXSRC} ${FigSRC:%.fig=%.tex} ${PicSRC:%.fig=%.pstex} ${BIBSRC} Makefile | ${Build} + ${LaTeX} ${BASE} + ${BibTeX} ${Build}/${BASE} + ${LaTeX} ${BASE} + # if nedded, run latex again to get citations + if fgrep -s "LaTeX Warning: Citation" ${basename $@}.log ; then ${LaTeX} ${BASE} ; fi +# ${Glossary} ${Build}/${BASE} +# ${LaTeX} ${BASE} + +${Build}: mkdir $@ -%.pdf : ${BUILD}/%.ps | ${BUILD} +%.pdf : ${Build}/%.ps | ${Build} ps2pdf $< -%.ps : %.dvi | ${BUILD} +%.ps : %.dvi | ${Build} dvips $< -o $@ -%.tex : %.fig | ${BUILD} - fig2dev -L eepic $< > ${BUILD}/$@ +%.tex : %.fig | ${Build} + fig2dev -L eepic $< > ${Build}/$@ -%.ps : %.fig | ${BUILD} - fig2dev -L ps $< > ${BUILD}/$@ +%.ps : %.fig | ${Build} + fig2dev -L ps $< > ${Build}/$@ -%.pstex : %.fig | ${BUILD} - fig2dev -L pstex $< > ${BUILD}/$@ - fig2dev -L pstex_t -p ${BUILD}/$@ $< > ${BUILD}/$@_t - -clean: - @rm -frv ${DOC} ${BUILD} *.fig.bak +%.pstex : %.fig | ${Build} + fig2dev -L pstex $< > ${Build}/$@ + fig2dev -L pstex_t -p ${Build}/$@ $< > ${Build}/$@_t Index: doc/theses/mubeen_zulfiqar_MMath/allocator.tex =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/allocator.tex (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ doc/theses/mubeen_zulfiqar_MMath/allocator.tex (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -24,5 +24,5 @@ \end{itemize} -The new features added to uHeapLmmm (incl. @malloc\_size@ routine) +The new features added to uHeapLmmm (incl. @malloc_size@ routine) \CFA alloc interface with examples. @@ -99,7 +99,7 @@ \begin{itemize} \item -The bump allocation is concurrent as memory taken from sbrk is sharded across all heaps as bump allocation reserve. The lock on bump allocation (on memory taken from sbrk) will only be contended if KTs > N. The contention on sbrk area is less likely as it will only happen in the case if heaps assigned to two KTs get short of bump allocation reserve simultanously. -\item -N heaps are created at the start of the program and destroyed at the end of program. When a KT is created, we only assign it to one of the heaps. When a KT is destroyed, we only dissociate it from the assigned heap but we do not destroy that heap. That heap will go back to our pool-of-heaps, ready to be used by some new KT. And if that heap was shared among multiple KTs (like the case of KTs > N) then, on deletion of one KT, that heap will be still in-use of the other KTs. This will prevent creation and deletion of heaps during run-time as heaps are re-usable which helps in keeping low-memory footprint. +The bump allocation is concurrent as memory taken from sbrk is sharded across all heaps as bump allocation reserve. The lock on bump allocation (on memory taken from sbrk) will only be contended if KTs $<$ N. The contention on sbrk area is less likely as it will only happen in the case if heaps assigned to two KTs get short of bump allocation reserve simultanously. +\item +N heaps are created at the start of the program and destroyed at the end of program. When a KT is created, we only assign it to one of the heaps. When a KT is destroyed, we only dissociate it from the assigned heap but we do not destroy that heap. That heap will go back to our pool-of-heaps, ready to be used by some new KT. And if that heap was shared among multiple KTs (like the case of KTs $<$ N) then, on deletion of one KT, that heap will be still in-use of the other KTs. This will prevent creation and deletion of heaps during run-time as heaps are re-usable which helps in keeping low-memory footprint. \item It is possible to use sharing and stealing techniques to share/find unused storage, when a free list is unused or empty. @@ -113,37 +113,37 @@ \section{Added Features and Methods} -To improve the UHeapLmmm allocator (FIX ME: cite uHeapLmmm) interface and make it more user friendly, we added a few more routines to the C allocator. Also, we built a CFA (FIX ME: cite cforall) interface on top of C interface to increase the usability of the allocator. +To improve the UHeapLmmm allocator (FIX ME: cite uHeapLmmm) interface and make it more user friendly, we added a few more routines to the C allocator. Also, we built a \CFA (FIX ME: cite cforall) interface on top of C interface to increase the usability of the allocator. \subsection{C Interface} We added a few more features and routines to the allocator's C interface that can make the allocator more usable to the programmers. THese features will programmer more control on the dynamic memory allocation. -\subsubsection void * aalloc( size\_t dim, size\_t elemSize ) -aalloc is an extension of malloc. It allows programmer to allocate a dynamic array of objects without calculating the total size of array explicitly. The only alternate of this routine in the other allocators is calloc but calloc also fills the dynamic memory with 0 which makes it slower for a programmer who only wants to dynamically allocate an array of objects without filling it with 0. -\paragraph{Usage} -aalloc takes two parameters. - -\begin{itemize} -\item -dim: number of objects in the array -\item -elemSize: size of the object in the array. -\end{itemize} -It returns address of dynamic object allocatoed on heap that can contain dim number of objects of the size elemSize. On failure, it returns NULL pointer. - -\subsubsection void * resize( void * oaddr, size\_t size ) -resize is an extension of relloc. It allows programmer to reuse a cuurently allocated dynamic object with a new size requirement. Its alternate in the other allocators is realloc but relloc also copy the data in old object to the new object which makes it slower for the programmer who only wants to reuse an old dynamic object for a new size requirement but does not want to preserve the data in the old object to the new object. -\paragraph{Usage} -resize takes two parameters. - -\begin{itemize} -\item -oaddr: the address of the old object that needs to be resized. -\item -size: the new size requirement of the to which the old object needs to be resized. -\end{itemize} -It returns an object that is of the size given but it does not preserve the data in the old object. On failure, it returns NULL pointer. - -\subsubsection void * resize( void * oaddr, size\_t nalign, size\_t size ) -This resize is an extension of the above resize (FIX ME: cite above resize). In addition to resizing the size of of an old object, it can also realign the old object to a new alignment requirement. +\subsection{\lstinline{void * aalloc( size_t dim, size_t elemSize )}} +@aalloc@ is an extension of malloc. It allows programmer to allocate a dynamic array of objects without calculating the total size of array explicitly. The only alternate of this routine in the other allocators is calloc but calloc also fills the dynamic memory with 0 which makes it slower for a programmer who only wants to dynamically allocate an array of objects without filling it with 0. +\paragraph{Usage} +@aalloc@ takes two parameters. + +\begin{itemize} +\item +@dim@: number of objects in the array +\item +@elemSize@: size of the object in the array. +\end{itemize} +It returns address of dynamic object allocatoed on heap that can contain dim number of objects of the size elemSize. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{void * resize( void * oaddr, size_t size )}} +@resize@ is an extension of relloc. It allows programmer to reuse a cuurently allocated dynamic object with a new size requirement. Its alternate in the other allocators is @realloc@ but relloc also copy the data in old object to the new object which makes it slower for the programmer who only wants to reuse an old dynamic object for a new size requirement but does not want to preserve the data in the old object to the new object. +\paragraph{Usage} +@resize@ takes two parameters. + +\begin{itemize} +\item +@oaddr@: the address of the old object that needs to be resized. +\item +@size@: the new size requirement of the to which the old object needs to be resized. +\end{itemize} +It returns an object that is of the size given but it does not preserve the data in the old object. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{void * resize( void * oaddr, size_t nalign, size_t size )}} +This @resize@ is an extension of the above @resize@ (FIX ME: cite above resize). In addition to resizing the size of of an old object, it can also realign the old object to a new alignment requirement. \paragraph{Usage} This resize takes three parameters. It takes an additional parameter of nalign as compared to the above resize (FIX ME: cite above resize). @@ -151,13 +151,13 @@ \begin{itemize} \item -oaddr: the address of the old object that needs to be resized. -\item -nalign: the new alignment to which the old object needs to be realigned. -\item -size: the new size requirement of the to which the old object needs to be resized. -\end{itemize} -It returns an object with the size and alignment given in the parameters. On failure, it returns a NULL pointer. - -\subsubsection void * amemalign( size\_t alignment, size\_t dim, size\_t elemSize ) +@oaddr@: the address of the old object that needs to be resized. +\item +@nalign@: the new alignment to which the old object needs to be realigned. +\item +@size@: the new size requirement of the to which the old object needs to be resized. +\end{itemize} +It returns an object with the size and alignment given in the parameters. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{void * amemalign( size_t alignment, size_t dim, size_t elemSize )}} amemalign is a hybrid of memalign and aalloc. It allows programmer to allocate an aligned dynamic array of objects without calculating the total size of the array explicitly. It frees the programmer from calculating the total size of the array. \paragraph{Usage} @@ -166,13 +166,13 @@ \begin{itemize} \item -alignment: the alignment to which the dynamic array needs to be aligned. -\item -dim: number of objects in the array -\item -elemSize: size of the object in the array. -\end{itemize} -It returns a dynamic array of objects that has the capacity to contain dim number of objects of the size of elemSize. The returned dynamic array is aligned to the given alignment. On failure, it returns NULL pointer. - -\subsubsection void * cmemalign( size\_t alignment, size\_t dim, size\_t elemSize ) +@alignment@: the alignment to which the dynamic array needs to be aligned. +\item +@dim@: number of objects in the array +\item +@elemSize@: size of the object in the array. +\end{itemize} +It returns a dynamic array of objects that has the capacity to contain dim number of objects of the size of elemSize. The returned dynamic array is aligned to the given alignment. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{void * cmemalign( size_t alignment, size_t dim, size_t elemSize )}} cmemalign is a hybrid of amemalign and calloc. It allows programmer to allocate an aligned dynamic array of objects that is 0 filled. The current way to do this in other allocators is to allocate an aligned object with memalign and then fill it with 0 explicitly. This routine provides both features of aligning and 0 filling, implicitly. \paragraph{Usage} @@ -181,71 +181,71 @@ \begin{itemize} \item -alignment: the alignment to which the dynamic array needs to be aligned. -\item -dim: number of objects in the array -\item -elemSize: size of the object in the array. -\end{itemize} -It returns a dynamic array of objects that has the capacity to contain dim number of objects of the size of elemSize. The returned dynamic array is aligned to the given alignment and is 0 filled. On failure, it returns NULL pointer. - -\subsubsection size\_t malloc\_alignment( void * addr ) -malloc\_alignment returns the alignment of a currently allocated dynamic object. It allows the programmer in memory management and personal bookkeeping. It helps the programmer in verofying the alignment of a dynamic object especially in a scenerio similar to prudcer-consumer where a producer allocates a dynamic object and the consumer needs to assure that the dynamic object was allocated with the required alignment. -\paragraph{Usage} -malloc\_alignment takes one parameters. - -\begin{itemize} -\item -addr: the address of the currently allocated dynamic object. -\end{itemize} -malloc\_alignment returns the alignment of the given dynamic object. On failure, it return the value of default alignment of the uHeapLmmm allocator. - -\subsubsection bool malloc\_zero\_fill( void * addr ) -malloc\_zero\_fill returns whether a currently allocated dynamic object was initially zero filled at the time of allocation. It allows the programmer in memory management and personal bookkeeping. It helps the programmer in verifying the zero filled property of a dynamic object especially in a scenerio similar to prudcer-consumer where a producer allocates a dynamic object and the consumer needs to assure that the dynamic object was zero filled at the time of allocation. -\paragraph{Usage} -malloc\_zero\_fill takes one parameters. - -\begin{itemize} -\item -addr: the address of the currently allocated dynamic object. -\end{itemize} -malloc\_zero\_fill returns true if the dynamic object was initially zero filled and return false otherwise. On failure, it returns false. - -\subsubsection size\_t malloc\_size( void * addr ) -malloc\_size returns the allocation size of a currently allocated dynamic object. It allows the programmer in memory management and personal bookkeeping. It helps the programmer in verofying the alignment of a dynamic object especially in a scenerio similar to prudcer-consumer where a producer allocates a dynamic object and the consumer needs to assure that the dynamic object was allocated with the required size. Its current alternate in the other allocators is malloc\_usable\_size. But, malloc\_size is different from malloc\_usable\_size as malloc\_usabe\_size returns the total data capacity of dynamic object including the extra space at the end of the dynamic object. On the other hand, malloc\_size returns the size that was given to the allocator at the allocation of the dynamic object. This size is updated when an object is realloced, resized, or passed through a similar allocator routine. -\paragraph{Usage} -malloc\_size takes one parameters. - -\begin{itemize} -\item -addr: the address of the currently allocated dynamic object. -\end{itemize} -malloc\_size returns the allocation size of the given dynamic object. On failure, it return zero. - -\subsubsection void * realloc( void * oaddr, size\_t nalign, size\_t size ) -This realloc is an extension of the default realloc (FIX ME: cite default realloc). In addition to reallocating an old object and preserving the data in old object, it can also realign the old object to a new alignment requirement. -\paragraph{Usage} -This realloc takes three parameters. It takes an additional parameter of nalign as compared to the default realloc. - -\begin{itemize} -\item -oaddr: the address of the old object that needs to be reallocated. -\item -nalign: the new alignment to which the old object needs to be realigned. -\item -size: the new size requirement of the to which the old object needs to be resized. -\end{itemize} -It returns an object with the size and alignment given in the parameters that preserves the data in the old object. On failure, it returns a NULL pointer. - -\subsection{CFA Malloc Interface} -We added some routines to the malloc interface of CFA. These routines can only be used in CFA and not in our standalone uHeapLmmm allocator as these routines use some features that are only provided by CFA and not by C. It makes the allocator even more usable to the programmers. -CFA provides the liberty to know the returned type of a call to the allocator. So, mainly in these added routines, we removed the object size parameter from the routine as allocator can calculate the size of the object from the returned type. - -\subsubsection T * malloc( void ) +@alignment@: the alignment to which the dynamic array needs to be aligned. +\item +@dim@: number of objects in the array +\item +@elemSize@: size of the object in the array. +\end{itemize} +It returns a dynamic array of objects that has the capacity to contain dim number of objects of the size of elemSize. The returned dynamic array is aligned to the given alignment and is 0 filled. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{size_t malloc_alignment( void * addr )}} +@malloc_alignment@ returns the alignment of a currently allocated dynamic object. It allows the programmer in memory management and personal bookkeeping. It helps the programmer in verofying the alignment of a dynamic object especially in a scenerio similar to prudcer-consumer where a producer allocates a dynamic object and the consumer needs to assure that the dynamic object was allocated with the required alignment. +\paragraph{Usage} +@malloc_alignment@ takes one parameters. + +\begin{itemize} +\item +@addr@: the address of the currently allocated dynamic object. +\end{itemize} +@malloc_alignment@ returns the alignment of the given dynamic object. On failure, it return the value of default alignment of the uHeapLmmm allocator. + +\subsection{\lstinline{bool malloc_zero_fill( void * addr )}} +@malloc_zero_fill@ returns whether a currently allocated dynamic object was initially zero filled at the time of allocation. It allows the programmer in memory management and personal bookkeeping. It helps the programmer in verifying the zero filled property of a dynamic object especially in a scenerio similar to prudcer-consumer where a producer allocates a dynamic object and the consumer needs to assure that the dynamic object was zero filled at the time of allocation. +\paragraph{Usage} +@malloc_zero_fill@ takes one parameters. + +\begin{itemize} +\item +@addr@: the address of the currently allocated dynamic object. +\end{itemize} +@malloc_zero_fill@ returns true if the dynamic object was initially zero filled and return false otherwise. On failure, it returns false. + +\subsection{\lstinline{size_t malloc_size( void * addr )}} +@malloc_size@ returns the allocation size of a currently allocated dynamic object. It allows the programmer in memory management and personal bookkeeping. It helps the programmer in verofying the alignment of a dynamic object especially in a scenerio similar to prudcer-consumer where a producer allocates a dynamic object and the consumer needs to assure that the dynamic object was allocated with the required size. Its current alternate in the other allocators is @malloc_usable_size@. But, @malloc_size@ is different from @malloc_usable_size@ as @malloc_usabe_size@ returns the total data capacity of dynamic object including the extra space at the end of the dynamic object. On the other hand, @malloc_size@ returns the size that was given to the allocator at the allocation of the dynamic object. This size is updated when an object is realloced, resized, or passed through a similar allocator routine. +\paragraph{Usage} +@malloc_size@ takes one parameters. + +\begin{itemize} +\item +@addr@: the address of the currently allocated dynamic object. +\end{itemize} +@malloc_size@ returns the allocation size of the given dynamic object. On failure, it return zero. + +\subsection{\lstinline{void * realloc( void * oaddr, size_t nalign, size_t size )}} +This @realloc@ is an extension of the default @realloc@ (FIX ME: cite default @realloc@). In addition to reallocating an old object and preserving the data in old object, it can also realign the old object to a new alignment requirement. +\paragraph{Usage} +This @realloc@ takes three parameters. It takes an additional parameter of nalign as compared to the default @realloc@. + +\begin{itemize} +\item +@oaddr@: the address of the old object that needs to be reallocated. +\item +@nalign@: the new alignment to which the old object needs to be realigned. +\item +@size@: the new size requirement of the to which the old object needs to be resized. +\end{itemize} +It returns an object with the size and alignment given in the parameters that preserves the data in the old object. On failure, it returns a @NULL@ pointer. + +\subsection{\CFA Malloc Interface} +We added some routines to the malloc interface of \CFA. These routines can only be used in \CFA and not in our standalone uHeapLmmm allocator as these routines use some features that are only provided by \CFA and not by C. It makes the allocator even more usable to the programmers. +\CFA provides the liberty to know the returned type of a call to the allocator. So, mainly in these added routines, we removed the object size parameter from the routine as allocator can calculate the size of the object from the returned type. + +\subsection{\lstinline{T * malloc( void )}} This malloc is a simplified polymorphic form of defualt malloc (FIX ME: cite malloc). It does not take any parameter as compared to default malloc that takes one parameter. \paragraph{Usage} This malloc takes no parameters. -It returns a dynamic object of the size of type T. On failure, it return NULL pointer. - -\subsubsection T * aalloc( size\_t dim ) +It returns a dynamic object of the size of type @T@. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * aalloc( size_t dim )}} This aalloc is a simplified polymorphic form of above aalloc (FIX ME: cite aalloc). It takes one parameter as compared to the above aalloc that takes two parameters. \paragraph{Usage} @@ -254,9 +254,9 @@ \begin{itemize} \item -dim: required number of objects in the array. -\end{itemize} -It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type T. On failure, it return NULL pointer. - -\subsubsection T * calloc( size\_t dim ) +@dim@: required number of objects in the array. +\end{itemize} +It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type @T@. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * calloc( size_t dim )}} This calloc is a simplified polymorphic form of defualt calloc (FIX ME: cite calloc). It takes one parameter as compared to the default calloc that takes two parameters. \paragraph{Usage} @@ -265,10 +265,10 @@ \begin{itemize} \item -dim: required number of objects in the array. -\end{itemize} -It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type T. On failure, it return NULL pointer. - -\subsubsection T * resize( T * ptr, size\_t size ) -This resize is a simplified polymorphic form of above resize (FIX ME: cite resize with alignment). It takes two parameters as compared to the above resize that takes three parameters. It frees the programmer from explicitly mentioning the alignment of the allocation as CFA provides gives allocator the liberty to get the alignment of the returned type. +@dim@: required number of objects in the array. +\end{itemize} +It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type @T@. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * resize( T * ptr, size_t size )}} +This resize is a simplified polymorphic form of above resize (FIX ME: cite resize with alignment). It takes two parameters as compared to the above resize that takes three parameters. It frees the programmer from explicitly mentioning the alignment of the allocation as \CFA provides gives allocator the liberty to get the alignment of the returned type. \paragraph{Usage} This resize takes two parameters. @@ -276,24 +276,24 @@ \begin{itemize} \item -ptr: address of the old object. -\item -size: the required size of the new object. -\end{itemize} -It returns a dynamic object of the size given in paramters. The returned object is aligned to the alignemtn of type T. On failure, it return NULL pointer. - -\subsubsection T * realloc( T * ptr, size\_t size ) -This realloc is a simplified polymorphic form of defualt realloc (FIX ME: cite realloc with align). It takes two parameters as compared to the above realloc that takes three parameters. It frees the programmer from explicitly mentioning the alignment of the allocation as CFA provides gives allocator the liberty to get the alignment of the returned type. -\paragraph{Usage} -This realloc takes two parameters. - -\begin{itemize} -\item -ptr: address of the old object. -\item -size: the required size of the new object. -\end{itemize} -It returns a dynamic object of the size given in paramters that preserves the data in the given object. The returned object is aligned to the alignemtn of type T. On failure, it return NULL pointer. - -\subsubsection T * memalign( size\_t align ) +@ptr@: address of the old object. +\item +@size@: the required size of the new object. +\end{itemize} +It returns a dynamic object of the size given in paramters. The returned object is aligned to the alignemtn of type @T@. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * realloc( T * ptr, size_t size )}} +This @realloc@ is a simplified polymorphic form of defualt @realloc@ (FIX ME: cite @realloc@ with align). It takes two parameters as compared to the above @realloc@ that takes three parameters. It frees the programmer from explicitly mentioning the alignment of the allocation as \CFA provides gives allocator the liberty to get the alignment of the returned type. +\paragraph{Usage} +This @realloc@ takes two parameters. + +\begin{itemize} +\item +@ptr@: address of the old object. +\item +@size@: the required size of the new object. +\end{itemize} +It returns a dynamic object of the size given in paramters that preserves the data in the given object. The returned object is aligned to the alignemtn of type @T@. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * memalign( size_t align )}} This memalign is a simplified polymorphic form of defualt memalign (FIX ME: cite memalign). It takes one parameters as compared to the default memalign that takes two parameters. \paragraph{Usage} @@ -302,9 +302,9 @@ \begin{itemize} \item -align: the required alignment of the dynamic object. -\end{itemize} -It returns a dynamic object of the size of type T that is aligned to given parameter align. On failure, it return NULL pointer. - -\subsubsection T * amemalign( size\_t align, size\_t dim ) +@align@: the required alignment of the dynamic object. +\end{itemize} +It returns a dynamic object of the size of type @T@ that is aligned to given parameter align. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * amemalign( size_t align, size_t dim )}} This amemalign is a simplified polymorphic form of above amemalign (FIX ME: cite amemalign). It takes two parameter as compared to the above amemalign that takes three parameters. \paragraph{Usage} @@ -313,11 +313,11 @@ \begin{itemize} \item -align: required alignment of the dynamic array. -\item -dim: required number of objects in the array. -\end{itemize} -It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type T. The returned object is aligned to the given parameter align. On failure, it return NULL pointer. - -\subsubsection T * cmemalign( size\_t align, size\_t dim ) +@align@: required alignment of the dynamic array. +\item +@dim@: required number of objects in the array. +\end{itemize} +It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type @T@. The returned object is aligned to the given parameter align. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * cmemalign( size_t align, size_t dim )}} This cmemalign is a simplified polymorphic form of above cmemalign (FIX ME: cite cmemalign). It takes two parameter as compared to the above cmemalign that takes three parameters. \paragraph{Usage} @@ -326,49 +326,48 @@ \begin{itemize} \item -align: required alignment of the dynamic array. -\item -dim: required number of objects in the array. -\end{itemize} -It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type T. The returned object is aligned to the given parameter align and is zero filled. On failure, it return NULL pointer. - -\subsubsection T * aligned\_alloc( size\_t align ) -This aligned\_alloc is a simplified polymorphic form of defualt aligned\_alloc (FIX ME: cite aligned\_alloc). It takes one parameter as compared to the default aligned\_alloc that takes two parameters. -\paragraph{Usage} -This aligned\_alloc takes one parameter. - -\begin{itemize} -\item -align: required alignment of the dynamic object. -\end{itemize} -It returns a dynamic object of the size of type T that is aligned to the given parameter. On failure, it return NULL pointer. - -\subsubsection int posix\_memalign( T ** ptr, size\_t align ) -This posix\_memalign is a simplified polymorphic form of defualt posix\_memalign (FIX ME: cite posix\_memalign). It takes two parameters as compared to the default posix\_memalign that takes three parameters. -\paragraph{Usage} -This posix\_memalign takes two parameter. - -\begin{itemize} -\item -ptr: variable address to store the address of the allocated object. -\item -align: required alignment of the dynamic object. -\end{itemize} - -It stores address of the dynamic object of the size of type T in given parameter ptr. This object is aligned to the given parameter. On failure, it return NULL pointer. - -\subsubsection T * valloc( void ) -This valloc is a simplified polymorphic form of defualt valloc (FIX ME: cite valloc). It takes no parameters as compared to the default valloc that takes one parameter. -\paragraph{Usage} -valloc takes no parameters. -It returns a dynamic object of the size of type T that is aligned to the page size. On failure, it return NULL pointer. - -\subsubsection T * pvalloc( void ) -This pcvalloc is a simplified polymorphic form of defualt pcvalloc (FIX ME: cite pcvalloc). It takes no parameters as compared to the default pcvalloc that takes one parameter. -\paragraph{Usage} -pvalloc takes no parameters. -It returns a dynamic object of the size that is calcutaed by rouding the size of type T. The returned object is also aligned to the page size. On failure, it return NULL pointer. - -\subsection Alloc Interface -In addition to improve allocator interface both for CFA and our standalone allocator uHeapLmmm in C. We also added a new alloc interface in CFA that increases usability of dynamic memory allocation. +@align@: required alignment of the dynamic array. +\item +@dim@: required number of objects in the array. +\end{itemize} +It returns a dynamic object that has the capacity to contain dim number of objects, each of the size of type @T@. The returned object is aligned to the given parameter align and is zero filled. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * aligned_alloc( size_t align )}} +This @aligned_alloc@ is a simplified polymorphic form of defualt @aligned_alloc@ (FIX ME: cite @aligned_alloc@). It takes one parameter as compared to the default @aligned_alloc@ that takes two parameters. +\paragraph{Usage} +This @aligned_alloc@ takes one parameter. + +\begin{itemize} +\item +@align@: required alignment of the dynamic object. +\end{itemize} +It returns a dynamic object of the size of type @T@ that is aligned to the given parameter. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{int posix_memalign( T ** ptr, size_t align )}} +This @posix_memalign@ is a simplified polymorphic form of defualt @posix_memalign@ (FIX ME: cite @posix_memalign@). It takes two parameters as compared to the default @posix_memalign@ that takes three parameters. +\paragraph{Usage} +This @posix_memalign@ takes two parameter. + +\begin{itemize} +\item +@ptr@: variable address to store the address of the allocated object. +\item +@align@: required alignment of the dynamic object. +\end{itemize} + +It stores address of the dynamic object of the size of type @T@ in given parameter ptr. This object is aligned to the given parameter. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * valloc( void )}} +This @valloc@ is a simplified polymorphic form of defualt @valloc@ (FIX ME: cite @valloc@). It takes no parameters as compared to the default @valloc@ that takes one parameter. +\paragraph{Usage} +@valloc@ takes no parameters. +It returns a dynamic object of the size of type @T@ that is aligned to the page size. On failure, it returns a @NULL@ pointer. + +\subsection{\lstinline{T * pvalloc( void )}} +\paragraph{Usage} +@pvalloc@ takes no parameters. +It returns a dynamic object of the size that is calcutaed by rouding the size of type @T@. The returned object is also aligned to the page size. On failure, it returns a @NULL@ pointer. + +\subsection{Alloc Interface} +In addition to improve allocator interface both for \CFA and our standalone allocator uHeapLmmm in C. We also added a new alloc interface in \CFA that increases usability of dynamic memory allocation. This interface helps programmers in three major ways. @@ -379,52 +378,52 @@ Parametre Positions: alloc interface frees programmers from remembering parameter postions in call to routines. \item -Object Size: alloc interface does not require programmer to mention the object size as CFA allows allocator to determince the object size from returned type of alloc call. -\end{itemize} - -Alloc interface uses polymorphism, backtick routines (FIX ME: cite backtick) and ttype parameters of CFA (FIX ME: cite ttype) to provide a very simple dynamic memory allocation interface to the programmers. The new interfece has just one routine name alloc that can be used to perform a wide range of dynamic allocations. The parameters use backtick functions to provide a similar-to named parameters feature for our alloc interface so that programmers do not have to remember parameter positions in alloc call except the position of dimension (dim) parameter. - -\subsubsection{Routine: T * alloc( ... )} -Call to alloc wihout any parameter returns one object of size of type T allocated dynamically. +Object Size: alloc interface does not require programmer to mention the object size as \CFA allows allocator to determince the object size from returned type of alloc call. +\end{itemize} + +Alloc interface uses polymorphism, backtick routines (FIX ME: cite backtick) and ttype parameters of \CFA (FIX ME: cite ttype) to provide a very simple dynamic memory allocation interface to the programmers. The new interfece has just one routine name alloc that can be used to perform a wide range of dynamic allocations. The parameters use backtick functions to provide a similar-to named parameters feature for our alloc interface so that programmers do not have to remember parameter positions in alloc call except the position of dimension (dim) parameter. + +\subsection{Routine: \lstinline{T * alloc( ... )}} +Call to alloc wihout any parameter returns one object of size of type @T@ allocated dynamically. Only the dimension (dim) parameter for array allocation has the fixed position in the alloc routine. If programmer wants to allocate an array of objects that the required number of members in the array has to be given as the first parameter to the alloc routine. -alocc routine accepts six kinds of arguments. Using different combinations of tha parameters, different kind of allocations can be performed. Any combincation of parameters can be used together except `realloc and `resize that should not be used simultanously in one call to routine as it creates ambiguity about whether to reallocate or resize a currently allocated dynamic object. If both `resize and `realloc are used in a call to alloc then the latter one will take effect or unexpected resulted might be produced. +alocc routine accepts six kinds of arguments. Using different combinations of tha parameters, different kind of allocations can be performed. Any combincation of parameters can be used together except @`realloc@ and @`resize@ that should not be used simultanously in one call to routine as it creates ambiguity about whether to reallocate or resize a currently allocated dynamic object. If both @`resize@ and @`realloc@ are used in a call to alloc then the latter one will take effect or unexpected resulted might be produced. \paragraph{Dim} -This is the only parameter in the alloc routine that has a fixed-position and it is also the only parameter that does not use a backtick function. It has to be passed at the first position to alloc call in-case of an array allocation of objects of type T. -It represents the required number of members in the array allocation as in CFA's aalloc (FIX ME: cite aalloc). -This parameter should be of type size\_t. - -Example: int a = alloc( 5 ) +This is the only parameter in the alloc routine that has a fixed-position and it is also the only parameter that does not use a backtick function. It has to be passed at the first position to alloc call in-case of an array allocation of objects of type @T@. +It represents the required number of members in the array allocation as in \CFA's aalloc (FIX ME: cite aalloc). +This parameter should be of type @size_t@. + +Example: @int a = alloc( 5 )@ This call will return a dynamic array of five integers. \paragraph{Align} -This parameter is position-free and uses a backtick routine align (`align). The parameter passed with `align should be of type size\_t. If the alignment parameter is not a power of two or is less than the default alignment of the allocator (that can be found out using routine libAlign in CFA) then the passed alignment parameter will be rejected and the default alignment will be used. - -Example: int b = alloc( 5 , 64`align ) +This parameter is position-free and uses a backtick routine align (@`align@). The parameter passed with @`align@ should be of type @size_t@. If the alignment parameter is not a power of two or is less than the default alignment of the allocator (that can be found out using routine libAlign in \CFA) then the passed alignment parameter will be rejected and the default alignment will be used. + +Example: @int b = alloc( 5 , 64`align )@ This call will return a dynamic array of five integers. It will align the allocated object to 64. \paragraph{Fill} -This parameter is position-free and uses a backtick routine fill (`fill). In case of realloc, only the extra space after copying the data in the old object will be filled with given parameter. +This parameter is position-free and uses a backtick routine fill (@`fill@). In case of @realloc@, only the extra space after copying the data in the old object will be filled with given parameter. Three types of parameters can be passed using `fill. \begin{itemize} \item -char: A char can be passed with `fill to fill the whole dynamic allocation with the given char recursively till the end of required allocation. -\item -Object of returned type: An object of type of returned type can be passed with `fill to fill the whole dynamic allocation with the given object recursively till the end of required allocation. -\item -Dynamic object of returned type: A dynamic object of type of returned type can be passed with `fill to fill the dynamic allocation with the given dynamic object. In this case, the allocated memory is not filled recursively till the end of allocation. The filling happen untill the end object passed to `fill or the end of requested allocation reaches. -\end{itemize} - -Example: int b = alloc( 5 , 'a'`fill ) +@char@: A char can be passed with @`fill@ to fill the whole dynamic allocation with the given char recursively till the end of required allocation. +\item +Object of returned type: An object of type of returned type can be passed with @`fill@ to fill the whole dynamic allocation with the given object recursively till the end of required allocation. +\item +Dynamic object of returned type: A dynamic object of type of returned type can be passed with @`fill@ to fill the dynamic allocation with the given dynamic object. In this case, the allocated memory is not filled recursively till the end of allocation. The filling happen untill the end object passed to @`fill@ or the end of requested allocation reaches. +\end{itemize} + +Example: @int b = alloc( 5 , 'a'`fill )@ This call will return a dynamic array of five integers. It will fill the allocated object with character 'a' recursively till the end of requested allocation size. -Example: int b = alloc( 5 , 4`fill ) +Example: @int b = alloc( 5 , 4`fill )@ This call will return a dynamic array of five integers. It will fill the allocated object with integer 4 recursively till the end of requested allocation size. -Example: int b = alloc( 5 , a`fill ) where a is a pointer of int type +Example: @int b = alloc( 5 , a`fill )@ where @a@ is a pointer of int type This call will return a dynamic array of five integers. It will copy data in a to the returned object non-recursively untill end of a or the newly allocated object is reached. \paragraph{Resize} -This parameter is position-free and uses a backtick routine resize (`resize). It represents the old dynamic object (oaddr) that the programmer wants to +This parameter is position-free and uses a backtick routine resize (@`resize@). It represents the old dynamic object (oaddr) that the programmer wants to \begin{itemize} \item @@ -435,17 +434,17 @@ fill with something. \end{itemize} -The data in old dynamic object will not be preserved in the new object. The type of object passed to `resize and the returned type of alloc call can be different. - -Example: int b = alloc( 5 , a`resize ) +The data in old dynamic object will not be preserved in the new object. The type of object passed to @`resize@ and the returned type of alloc call can be different. + +Example: @int b = alloc( 5 , a`resize )@ This call will resize object a to a dynamic array that can contain 5 integers. -Example: int b = alloc( 5 , a`resize , 32`align ) +Example: @int b = alloc( 5 , a`resize , 32`align )@ This call will resize object a to a dynamic array that can contain 5 integers. The returned object will also be aligned to 32. -Example: int b = alloc( 5 , a`resize , 32`align , 2`fill) +Example: @int b = alloc( 5 , a`resize , 32`align , 2`fill )@ This call will resize object a to a dynamic array that can contain 5 integers. The returned object will also be aligned to 32 and will be filled with 2. \paragraph{Realloc} -This parameter is position-free and uses a backtick routine realloc (`realloc). It represents the old dynamic object (oaddr) that the programmer wants to +This parameter is position-free and uses a backtick routine @realloc@ (@`realloc@). It represents the old dynamic object (oaddr) that the programmer wants to \begin{itemize} \item @@ -456,12 +455,12 @@ fill with something. \end{itemize} -The data in old dynamic object will be preserved in the new object. The type of object passed to `realloc and the returned type of alloc call cannot be different. - -Example: int b = alloc( 5 , a`realloc ) +The data in old dynamic object will be preserved in the new object. The type of object passed to @`realloc@ and the returned type of alloc call cannot be different. + +Example: @int b = alloc( 5 , a`realloc )@ This call will realloc object a to a dynamic array that can contain 5 integers. -Example: int b = alloc( 5 , a`realloc , 32`align ) +Example: @int b = alloc( 5 , a`realloc , 32`align )@ This call will realloc object a to a dynamic array that can contain 5 integers. The returned object will also be aligned to 32. -Example: int b = alloc( 5 , a`realloc , 32`align , 2`fill) +Example: @int b = alloc( 5 , a`realloc , 32`align , 2`fill )@ This call will resize object a to a dynamic array that can contain 5 integers. The returned object will also be aligned to 32. The extra space after copying data of a to the returned object will be filled with 2. Index: doc/theses/mubeen_zulfiqar_MMath/background.tex =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/background.tex (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ doc/theses/mubeen_zulfiqar_MMath/background.tex (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -1,3 +1,721 @@ \chapter{Background} + + + +\section{Memory-Allocator Background} +\label{s:MemoryAllocatorBackground} + +A program dynamically allocates and deallocates the storage for a variable, referred to as an \newterm{object}, through calls such as @malloc@ and @free@ in C, and @new@ and @delete@ in \CC. +Space for each allocated object comes from the dynamic-allocation zone. +A \newterm{memory allocator} is a complex data-structure and code that manages the layout of objects in the dynamic-allocation zone. +The management goals are to make allocation/deallocation operations as fast as possible while densely packing objects to make efficient use of memory. +Objects cannot be moved to aid the packing process. +The allocator grows or shrinks the dynamic-allocation zone to obtain storage for objects and reduce memory usage via operating-system calls, such as @mmap@ or @sbrk@ in UNIX. + + +\subsection{Allocator Components} +\label{s:AllocatorComponents} + +There are two important parts to a memory allocator, management and storage data (see \VRef[Figure]{f:AllocatorComponents}), collectively called the \newterm{heap}. +The \newterm{management data} is a data structure located at a known memory address and contains all information necessary to manage the storage data. +The management data starts with fixed-sized information in the static-data memory that flows into the dynamic-allocation memory. +The \newterm{storage data} is composed of allocated and freed objects, and reserved memory. +Allocated objects (white) are variable sized and allocated to and maintained by the program. +Freed objects (light grey) are memory deallocated by the program that is linked to form a list facilitating easy location of storage for new allocations. +Often the free list is chained internally so it does not consume additional storage, \ie the link fields are placed at known locations in the unused memory blocks. +Reserved memory (dark grey) is one or more blocks of memory obtained from the operating system but not yet allocated to the program; +if there are multiple reserved blocks, they are also chained together, usually internally. + +\begin{figure} +\centering +\input{AllocatorComponents} +\caption{Allocator Components (Heap)} +\label{f:AllocatorComponents} +\end{figure} + +Allocated and freed objects typically have additional management data embedded within them. +\VRef[Figure]{f:AllocatedObject} shows an allocated object with a header, trailer, and padding/spacing around the object. +The header contains information about the object, \eg size, type, etc. +The trailer may be used to simplify an allocation implementation, \eg coalescing, and/or for security purposes to mark the end of an object. +An object may be preceded by padding to ensure proper alignment. +Some algorithms quantize allocation requests into distinct sizes resulting in additional spacing after objects less than the quantized value. +When padding and spacing are necessary, neither can be used to satisfy a future allocation request while the current allocation exists. +A free object also contains management data, \eg size, chaining, etc. +The amount of management data for a free node defines the minimum allocation size, \eg if 16 bytes are needed for a free-list node, any allocation request less than 16 bytes must be rounded up, otherwise the free list cannot use internal chaining. +The information in an allocated or freed object is overwritten when it transitions from allocated to freed and vice-versa by new management information and possibly data. + +\begin{figure} +\centering +\input{AllocatedObject} +\caption{Allocated Object} +\label{f:AllocatedObject} +\end{figure} + + +\subsection{Single-Threaded Memory-Allocator} +\label{s:SingleThreadedMemoryAllocator} + +A single-threaded memory-allocator does not run any threads itself, but is used by a single-threaded program. +Because the memory allocator is only executed by a single thread, concurrency issues do not exist. +The primary issues in designing a single-threaded memory-allocator are fragmentation and locality. + + +\subsubsection{Fragmentation} +\label{s:Fragmentation} + +Fragmentation is memory requested from the operating system but not used by the program; +hence, allocated objects are not fragmentation. +Fragmentation is often divided into internal or external (see~\VRef[Figure]{f:InternalExternalFragmentation}). + +\begin{figure} +\centering +\input{IntExtFragmentation} +\caption{Internal and External Fragmentation} +\label{f:InternalExternalFragmentation} +\end{figure} + +\newterm{Internal fragmentation} is memory space that is allocated to the program, but is not intended to be accessed by the program, such as headers, trailers, padding, and spacing around an allocated object. +This memory is typically used by the allocator for management purposes or required by the architecture for correctness (\eg alignment). +Internal fragmentation is problematic when management space is a significant proportion of an allocated object. +For example, if internal fragmentation is as large as the object being managed, then the memory usage for that object is doubled. +An allocator should strive to keep internal management information to a minimum. + +\newterm{External fragmentation} is all memory space reserved from the operating system but not allocated to the program~\cite{Wilson95,Lim98,Siebert00}, which includes freed objects, all external management data, and reserved memory. +This memory is problematic in two ways: heap blowup and highly fragmented memory. +\newterm{Heap blowup} occurs when memory freed by the program is not reused for future allocations leading to potentially unbounded external fragmentation growth~\cite{Berger00}. +Heap blowup can occur due to allocator policies that are too restrictive in reusing freed memory. +Memory can become \newterm{highly fragmented} after multiple allocations and deallocations of objects. +\VRef[Figure]{f:MemoryFragmentation} shows an example of how a small block of memory fragments as objects are allocated and deallocated over time. +Blocks of free memory become smaller and non-contiguous making them less useful in serving allocation requests. +Memory is highly fragmented when the sizes of most free blocks are unusable. +For example, \VRef[Figure]{f:Contiguous} and \VRef[Figure]{f:HighlyFragmented} have the same quantity of external fragmentation, but \VRef[Figure]{f:HighlyFragmented} is highly fragmented. +If there is a request to allocate a large object, \VRef[Figure]{f:Contiguous} is more likely to be able to satisfy it with existing free memory, while \VRef[Figure]{f:HighlyFragmented} likely has to request more memory from the operating system. + +For a single-threaded memory allocator, three basic approaches for controlling fragmentation have been identified~\cite{Johnstone99}. +The first approach is a \newterm{sequential-fit algorithm} with one list of free objects that is searched for a block large enough to fit a requested object size. +Different search policies determine the free object selected, \eg the first free object large enough or closest to the requested size. +Any storage larger than the request can become spacing after the object or be split into a smaller free object. +The cost of the search depends on the shape and quality of the free list, \eg a linear versus a binary-tree free-list, a sorted versus unsorted free-list. + +\begin{figure} +\centering +\input{MemoryFragmentation} +\caption{Memory Fragmentation} +\label{f:MemoryFragmentation} +\vspace{10pt} +\subfigure[Contiguous]{ + \input{ContigFragmentation} + \label{f:Contiguous} +} % subfigure + \subfigure[Highly Fragmented]{ + \input{NonContigFragmentation} +\label{f:HighlyFragmented} +} % subfigure +\caption{Fragmentation Quality} +\label{f:FragmentationQuality} +\end{figure} + +The second approach is a \newterm{segregated} or \newterm{binning algorithm} with a set of lists for different sized freed objects. +When an object is allocated, the requested size is rounded up to the nearest bin-size, possibly with spacing after the object. +A binning algorithm is fast at finding free memory of the appropriate size and allocating it, since the first free object on the free list is used. +The fewer bin-sizes, the fewer lists need to be searched and maintained; +however, the bin sizes are less likely to closely fit the requested object size, leading to more internal fragmentation. +The more bin-sizes, the longer the search and the less likely free objects are to be reused, leading to more external fragmentation and potentially heap blowup. +A variation of the binning algorithm allows objects to be allocated to the requested size, but when an object is freed, it is placed on the free list of the next smallest or equal bin-size. +For example, with bin sizes of 8 and 16 bytes, a request for 12 bytes allocates only 12 bytes, but when the object is freed, it is placed on the 8-byte bin-list. +For subsequent requests, the bin free-lists contain objects of different sizes, ranging from one bin-size to the next (8-16 in this example), and a sequential-fit algorithm may be used to find an object large enough for the requested size on the associated bin list. + +The third approach is \newterm{splitting} and \newterm{coalescing algorithms}. +When an object is allocated, if there are no free objects of the requested size, a larger free object may be split into two smaller objects to satisfy the allocation request without obtaining more memory from the operating system. +For example, in the buddy system, a block of free memory is split into two equal chunks, one of those chunks is again split into two equal chunks, and so on until a block just large enough to fit the requested object is created. +When an object is deallocated it is coalesced with the objects immediately before and after it in memory, if they are free, turning them into one larger object. +Coalescing can be done eagerly at each deallocation or lazily when an allocation cannot be fulfilled. +While coalescing does not reduce external fragmentation, the coalesced blocks improve fragmentation quality so future allocations are less likely to cause heap blowup. +Splitting and coalescing can be used with other algorithms to avoid highly fragmented memory. + + +\subsubsection{Locality} +\label{s:Locality} + +The principle of locality recognizes that programs tend to reference a small set of data, called a working set, for a certain period of time, where a working set is composed of temporal and spatial accesses~\cite{Denning05}. +Temporal clustering implies a group of objects are accessed repeatedly within a short time period, while spatial clustering implies a group of objects physically close together (nearby addresses) are accessed repeatedly within a short time period. +Temporal locality commonly occurs during an iterative computation with a fix set of disjoint variables, while spatial locality commonly occurs when traversing an array. + +Hardware takes advantage of temporal and spatial locality through multiple levels of caching (\ie memory hierarchy). +When an object is accessed, the memory physically located around the object is also cached with the expectation that the current and nearby objects will be referenced within a short period of time. +For example, entire cache lines are transfered between memory and cache and entire virtual-memory pages are transferred between disk and memory. +A program exhibiting good locality has better performance due to fewer cache misses and page faults. + +Temporal locality is largely controlled by how a program accesses its variables~\cite{Feng05}. +Nevertheless, a memory allocator can have some indirect influence on temporal locality and largely dictates spatial locality. +For temporal locality, an allocator can return storage for new allocations that was just freed as these memory locations are still \emph{warm} in the memory hierarchy. +For spatial locality, an allocator can place objects used together close together in memory, so the working set of the program fits into the fewest possible cache lines and pages. +However, usage patterns are different for every program as is the underlying hardware architecture (\ie memory hierarchy); +hence, no general-purpose memory-allocator can provide ideal locality for every program on every computer. + +There are a number of ways a memory allocator can degrade locality by increasing the working set. +For example, a memory allocator may access multiple free objects before finding one to satisfy an allocation request (\eg sequential-fit algorithm). +If there are a (large) number of objects accessed in very different areas of memory, the allocator may perturb the program's memory hierarchy causing multiple cache or page misses~\cite{Grunwald93}. +Another way locality can be degraded is by spatially separating related data. +For example, in a binning allocator, objects of different sizes are allocated from different bins that may be located in different pages of memory. + + +\subsection{Multi-Threaded Memory-Allocator} +\label{s:MultiThreadedMemoryAllocator} + +A multi-threaded memory-allocator does not run any threads itself, but is used by a multi-threaded program. +In addition to single-threaded design issues of locality and fragmentation, a multi-threaded allocator may be simultaneously accessed by multiple threads, and hence, must deal with concurrency issues such as mutual exclusion, false sharing, and additional forms of heap blowup. + + +\subsubsection{Mutual Exclusion} +\label{s:MutualExclusion} + +Mutual exclusion provides sequential access to the management data of the heap. +There are two performance issues for mutual exclusion. +First is the overhead necessary to perform (at least) a hardware atomic operation every time a shared resource is accessed. +Second is when multiple threads contend for a shared resource simultaneously, and hence, some threads must wait until the resource is released. +Contention can be reduced in a number of ways: +using multiple fine-grained locks versus a single lock, spreading the contention across a number of locks; +using trylock and generating new storage if the lock is busy, yielding a space vs contention trade-off; +using one of the many lock-free approaches for reducing contention on basic data-structure operations~\cite{Oyama99}. +However, all of these approaches have degenerate cases where contention occurs. + + +\subsubsection{False Sharing} +\label{s:FalseSharing} + +False sharing is a dynamic phenomenon leading to cache thrashing. +When two or more threads on separate CPUs simultaneously change different objects sharing a cache line, the change invalidates the other thread's associated cache, even though these threads may be uninterested in the modified object. +False sharing can occur in three different ways: program induced, allocator-induced active, and allocator-induced passive; +a memory allocator can only affect the latter two. + +\newterm{Program-induced false-sharing} occurs when one thread passes an object sharing a cache line to another thread, and both threads modify the respective objects. +For example, in \VRef[Figure]{f:ProgramInducedFalseSharing}, when Task$_1$ passes Object$_2$ to Task$_2$, a false-sharing situation forms when Task$_1$ modifies Object$_1$ and Task$_2$ modifies Object$_2$. +Changes to Object$_1$ invalidate CPU$_2$'s cache line, and changes to Object$_2$ invalidate CPU$_1$'s cache line. + +\begin{figure} +\centering +\subfigure[Program-Induced False-Sharing]{ + \input{ProgramFalseSharing} + \label{f:ProgramInducedFalseSharing} +} \\ +\vspace{5pt} +\subfigure[Allocator-Induced Active False-Sharing]{ + \input{AllocInducedActiveFalseSharing} + \label{f:AllocatorInducedActiveFalseSharing} +} \\ +\vspace{5pt} +\subfigure[Allocator-Induced Passive False-Sharing]{ + \input{AllocInducedPassiveFalseSharing} + \label{f:AllocatorInducedPassiveFalseSharing} +} % subfigure +\caption{False Sharing} +\label{f:FalseSharing} +\end{figure} + +\newterm{Allocator-induced active false-sharing} occurs when objects are allocated within the same cache line but to different threads. +For example, in \VRef[Figure]{f:AllocatorInducedActiveFalseSharing}, each task allocates an object and loads a cache-line of memory into its associated cache. +Again, changes to Object$_1$ invalidate CPU$_2$'s cache line, and changes to Object$_2$ invalidate CPU$_1$'s cache line. + +\newterm{Allocator-induced passive false-sharing} is another form of allocator-induced false-sharing caused by program-induced false-sharing. +When an object in a program-induced false-sharing situation is deallocated, a future allocation of that object may cause passive false-sharing. +For example, in \VRef[Figure]{f:AllocatorInducedPassiveFalseSharing}, Task$_1$ passes Object$_2$ to Task$_2$, and Task$_2$ subsequently deallocates Object$_2$. +Allocator-induced passive false-sharing occurs when Object$_2$ is reallocated to Task$_2$ while Task$_1$ is still using Object$_1$. + + +\subsubsection{Heap Blowup} +\label{s:HeapBlowup} + +In a multi-threaded program, heap blowup can occur when memory freed by one thread is inaccessible to other threads due to the allocation strategy. +Specific examples are presented in later sections. + + +\section{Multi-Threaded Memory-Allocator Features} +\label{s:MultiThreadedMemoryAllocatorFeatures} + +By analyzing a suite of existing allocators (see \VRef{s:ExistingAllocators}), the following salient features were identified: +\begin{list}{\arabic{enumi}.}{\usecounter{enumi}\topsep=0.5ex\parsep=0pt\itemsep=0pt} +\item multiple heaps +\begin{list}{\alph{enumii})}{\usecounter{enumii}\topsep=0.5ex\parsep=0pt\itemsep=0pt} +\item with or without a global heap +\item with or without ownership +\end{list} +\item object containers +\begin{list}{\alph{enumii})}{\usecounter{enumii}\topsep=0.5ex\parsep=0pt\itemsep=0pt} +\item with or without ownership +\item fixed or variable sized +\item global or local free-lists +\end{list} +\item hybrid private/public heap +\item allocation buffer +\item lock-free operations +\end{list} +The first feature, multiple heaps, pertains to different kinds of heaps. +The second feature, object containers, pertains to the organization of objects within the storage area. +The remaining features apply to different parts of the allocator design or implementation. + + +\subsection{Multiple Heaps} +\label{s:MultipleHeaps} + +A single-threaded allocator has at most one thread and heap, while a multi-threaded allocator has potentially multiple threads and heaps. +The multiple threads cause complexity, and multiple heaps are a mechanism for dealing with the complexity. +The spectrum ranges from multiple threads using a single heap, denoted as T:1 (see \VRef[Figure]{f:SingleHeap}), to multiple threads sharing multiple heaps, denoted as T:H (see \VRef[Figure]{f:SharedHeaps}), to one thread per heap, denoted as 1:1 (see \VRef[Figure]{f:PerThreadHeap}), which is almost back to a single-threaded allocator. + +In the T:1 model, all threads allocate and deallocate objects from one heap. +Memory is obtained from the freed objects or reserved memory in the heap, or from the operating system (OS); +the heap may also return freed memory to the operating system. +The arrows indicate the direction memory conceptually moves for each kind of operation: allocation moves memory along the path from the heap/operating-system to the user application, while deallocation moves memory along the path from the application back to the heap/operating-system. +To safely handle concurrency, a single heap uses locking to provide mutual exclusion. +Whether using a single lock for all heap operations or fine-grained locking for different operations, a single heap may be a significant source of contention for programs with a large amount of memory allocation. + +\begin{figure} +\centering +\subfigure[T:1]{ +% \input{SingleHeap.pstex_t} + \input{SingleHeap} + \label{f:SingleHeap} +} % subfigure +\vrule +\subfigure[T:H]{ +% \input{MultipleHeaps.pstex_t} + \input{SharedHeaps} + \label{f:SharedHeaps} +} % subfigure +\vrule +\subfigure[1:1]{ +% \input{MultipleHeapsGlobal.pstex_t} + \input{PerThreadHeap} + \label{f:PerThreadHeap} +} % subfigure +\caption{Multiple Heaps, Thread:Heap Relationship} +\end{figure} + +In the T:H model, each thread allocates storage from several heaps depending on certain criteria, with the goal of reducing contention by spreading allocations/deallocations across the heaps. +The decision on when to create a new heap and which heap a thread allocates from depends on the allocator design. +The performance goal is to reduce the ratio of heaps to threads. +In general, locking is required, since more than one thread may concurrently access a heap during its lifetime, but contention is reduced because fewer threads access a specific heap. +Two examples of this approach are: +\begin{description} +\item[heap pool:] +Multiple heaps are managed in a pool, starting with a single or a fixed number of heaps that increase\-/decrease depending on contention\-/space issues. +At creation, a thread is associated with a heap from the pool. +When the thread attempts an allocation and its associated heap is locked (contention), it scans for an unlocked heap in the pool. +If an unlocked heap is found, the thread changes its association and uses that heap. +If all heaps are locked, the thread may create a new heap, use it, and then place the new heap into the pool; +or the thread can block waiting for a heap to become available. +While the heap-pool approach often minimizes the number of extant heaps, the worse case can result in more heaps than threads; +\eg if the number of threads is large at startup with many allocations creating a large number of heaps and then the number of threads reduces. +\item[kernel threads:] +Each kernel thread (CPU) executing an application has its own heap. +A thread allocates/deallocates from/to the heap of the kernel thread on which it is executing. +Special precautions must be taken to handle or prevent the case where a thread is preempted during allocation/deallocation and restarts execution on a different kernel thread~\cite{Dice02}. +\end{description} + +In the 1:1 model (thread heaps), each thread has its own heap, which eliminates contention and locking because no thread accesses another thread's heap. +An additional benefit of thread heaps is improved locality due to better memory layout. +As each thread only allocates from its heap, all objects for a thread are more consolidated in the storage area for that heap, better utilizing each CPUs cache and accessing fewer pages. +In contrast, the T:H model spreads each thread's objects over a larger area in different heaps. +Thread heaps can also eliminate allocator-induced active false-sharing, if memory is acquired so it does not overlap at crucial boundaries with memory for another thread's heap. +For example, assume page boundaries coincide with cache line boundaries, then if a thread heap always acquires pages of memory, no two threads share a page or cache line unless pointers are passed among them. +Hence, allocator-induced active false-sharing in \VRef[Figure]{f:AllocatorInducedActiveFalseSharing} cannot occur because the memory for thread heaps never overlaps. + +Threads using multiple heaps need to determine the specific heap to access for an allocation/deallocation, \ie association of thread to heap. +A number of techniques are used to establish this association. +The simplest approach is for each thread to have a pointer to its associated heap (or to administrative information that points to the heap), and this pointer changes if the association changes. +For threading systems with thread-local/specific storage, the heap pointer/data is created using this mechanism; +otherwise, the heap routines must use approaches like hashing the thread's stack-pointer or thread-id to find its associated heap. + +The storage management for multiple heaps is more complex than for a single heap (see \VRef[Figure]{f:AllocatorComponents}). +\VRef[Figure]{f:MultipleHeapStorage} illustrates the general storage layout for multiple heaps. +Allocated and free objects are labelled by the thread or heap they are associated with. +(Links between free objects are removed for simplicity.) +The management information in the static zone must be able to locate all heaps in the dynamic zone. +The management information for the heaps must reside in the dynamic-allocation zone if there are a variable number. +Each heap in the dynamic zone is composed of a list of a free objects and a pointer to its reserved memory. +An alternative implementation is for all heaps to share one reserved memory, which requires a separate lock for the reserved storage to ensure mutual exclusion when acquiring new memory. +Because multiple threads can allocate/free/reallocate adjacent storage, all forms of false sharing may occur. +Other storage-management options are to use @mmap@ to set aside (large) areas of virtual memory for each heap and suballocate each heap's storage within that area. + +\begin{figure} +\centering +\input{MultipleHeapsStorage} +\caption{Multiple-Heap Storage} +\label{f:MultipleHeapStorage} +\end{figure} + +Multiple heaps increase external fragmentation as the ratio of heaps to threads increases, which can lead to heap blowup. +The external fragmentation experienced by a program with a single heap is now multiplied by the number of heaps, since each heap manages its own free storage and allocates its own reserved memory. +Additionally, objects freed by one heap cannot be reused by other threads, except indirectly by returning free memory to the operating system, which can be expensive. +(Depending on how the operating system provides dynamic storage to an application, returning storage may be difficult or impossible, \eg the contiguous @sbrk@ area in Unix.) +In the worst case, a program in which objects are allocated from one heap but deallocated to another heap means these freed objects are never reused. + +Adding a \newterm{global heap} (G) attempts to reduce the cost of obtaining/returning memory among heaps (sharing) by buffering storage within the application address-space. +Now, each heap obtains and returns storage to/from the global heap rather than the operating system. +Storage is obtained from the global heap only when a heap allocation cannot be fulfilled, and returned to the global heap when a heap's free memory exceeds some threshold. +Similarly, the global heap buffers this memory, obtaining and returning storage to/from the operating system as necessary. +The global heap does not have its own thread and makes no internal allocation requests; +instead, it uses the application thread, which called one of the multiple heaps and then the global heap, to perform operations. +Hence, the worst-case cost of a memory operation includes all these steps. +With respect to heap blowup, the global heap provides an indirect mechanism to move free memory among heaps, which usually has a much lower cost than interacting with the operating system to achieve the same goal and is independent of the mechanism used by the operating system to present dynamic memory to an address space. + +However, since any thread may indirectly perform a memory operation on the global heap, it is a shared resource that requires locking. +A single lock can be used to protect the global heap or fine-grained locking can be used to reduce contention. +In general, the cost is minimal since the majority of memory operations are completed without the use of the global heap. + +For thread heaps, when a kernel/user-thread terminates, there are two options for handling its heap. +First is to free all objects in the heap to the global heap and destroy the thread heap. +Second is to place the thread heap on a list of available heaps and reuse it for a new kernel/user thread in the future. +Destroying the thread heap immediately may reduce external fragmentation sooner, since all free objects are freed to the global heap and may be reused by other threads. +Alternatively, reusing thread heaps may improve performance if the inheriting thread makes similar allocation requests as the thread that previously held the thread heap. + +As multiple heaps are a key feature for a multi-threaded allocator, all further discussion assumes multiple heaps with a global heap to eliminate direct interaction with the operating system. + + +\subsubsection{Ownership} +\label{s:Ownership} + +\newterm{Ownership} defines which heap an object is returned-to on deallocation. +If a thread returns an object to the heap it was originally allocated from, the heap has ownership of its objects. +Alternatively, a thread can return an object to the heap it is currently allocating from, which can be any heap accessible during a thread's lifetime. +\VRef[Figure]{f:HeapsOwnership} shows an example of multiple heaps (minus the global heap) with and without ownership. +Again, the arrows indicate the direction memory conceptually moves for each kind of operation. +For the 1:1 thread:heap relationship, a thread only allocates from its own heap, and without ownership, a thread only frees objects to its own heap, which means the heap is private to its owner thread and does not require any locking, called a \newterm{private heap}. +For the T:1/T:H models with or without ownership or the 1:1 model with ownership, a thread may free objects to different heaps, which makes each heap publicly accessible to all threads, called a \newterm{public heap}. + +\begin{figure} +\centering +\subfigure[Ownership]{ + \input{MultipleHeapsOwnership} +} % subfigure +\hspace{0.25in} +\subfigure[No Ownership]{ + \input{MultipleHeapsNoOwnership} +} % subfigure +\caption{Heap Ownership} +\label{f:HeapsOwnership} +\end{figure} + +\VRef[Figure]{f:MultipleHeapStorageOwnership} shows the effect of ownership on storage layout. +(For simplicity assume the heaps all use the same size of reserves storage.) +In contrast to \VRef[Figure]{f:MultipleHeapStorage}, each reserved area used by a heap only contains free storage for that particular heap because threads must return free objects back to the owner heap. +Again, because multiple threads can allocate/free/reallocate adjacent storage in the same heap, all forms of false sharing may occur. +The exception is for the 1:1 model if reserved memory does not overlap a cache-line because all allocated storage within a used area is associated with a single thread. +In this case, there is no allocator-induced active false-sharing (see \VRef[Figure]{f:AllocatorInducedActiveFalseSharing}) because two adjacent allocated objects used by different threads cannot share a cache-line. +As well, there is no allocator-induced passive false-sharing (see \VRef[Figure]{f:AllocatorInducedActiveFalseSharing}) because two adjacent allocated objects used by different threads cannot occur because free objects are returned to the owner heap. +% Passive false-sharing may still occur, if delayed ownership is used (see below). + +\begin{figure} +\centering +\input{MultipleHeapsOwnershipStorage.pstex_t} +\caption{Multiple-Heap Storage with Ownership} +\label{f:MultipleHeapStorageOwnership} +\end{figure} + +The main advantage of ownership is preventing heap blowup by returning storage for reuse by the owner heap. +Ownership prevents the classical problem where one thread performs allocations from one heap, passes the object to another thread, and the receiving thread deallocates the object to another heap, hence draining the initial heap of storage. +As well, allocator-induced passive false-sharing is eliminated because returning an object to its owner heap means it can never be allocated to another thread. +For example, in \VRef[Figure]{f:AllocatorInducedPassiveFalseSharing}, the deallocation by Task$_2$ returns Object$_2$ back to Task$_1$'s heap; +hence a subsequent allocation by Task$_2$ cannot return this storage. +The disadvantage of ownership is deallocating to another task's heap so heaps are no longer private and require locks to provide safe concurrent access. + +Object ownership can be immediate or delayed, meaning objects may be returned to the owner heap immediately at deallocation or after some delay. +A thread may delay the return by storing objects it does not own on a separate free list. +Delaying can improve performance by batching objects for return to their owner heap and possibly reallocating these objects if storage runs out on the current heap. +However, reallocation can result in passive false-sharing. +For example, in \VRef[Figure]{f:AllocatorInducedPassiveFalseSharing}, Object$_2$ may be deallocated to Task$_2$'s heap initially. +If Task$_2$ reallocates Object$_2$ before it is returned to its owner heap, then passive false-sharing may occur. + + +\subsection{Object Containers} +\label{s:ObjectContainers} + +One approach for managing objects places headers/trailers around individual objects, meaning memory adjacent to the object is reserved for object-management information, as shown in \VRef[Figure]{f:ObjectHeaders}. +However, this approach leads to poor cache usage, since only a portion of the cache line is holding useful information from the program's perspective. +Spatial locality is also negatively affected. +While the header and object are together in memory, they are generally not accessed together; +\eg the object is accessed by the program when it is allocated, while the header is accessed by the allocator when the object is free. +This difference in usage patterns can lead to poor cache locality~\cite{Feng05}. +Additionally, placing headers on individual objects can lead to redundant management information. +For example, if a header stores only the object size, then all objects with the same size have identical headers. + +\begin{figure} +\centering +\subfigure[Object Headers]{ + \input{ObjectHeaders} + \label{f:ObjectHeaders} +} % subfigure +\\ +\subfigure[Object Container]{ + \input{Container} + \label{f:ObjectContainer} +} % subfigure +\caption{Header Placement} +\label{f:HeaderPlacement} +\end{figure} + +An alternative approach for managing objects factors common header/trailer information to a separate location in memory and organizes associated free storage into blocks called \newterm{object containers} (\newterm{superblocks} in~\cite{Berger00}), as in \VRef[Figure]{f:ObjectContainer}. +The header for the container holds information necessary for all objects in the container; +a trailer may also be used at the end of the container. +Similar to the approach described for thread heaps in \VRef{s:MultipleHeaps}, if container boundaries do not overlap with memory of another container at crucial boundaries and all objects in a container are allocated to the same thread, allocator-induced active false-sharing is avoided. + +The difficulty with object containers lies in finding the object header/trailer given only the object address, since that is normally the only information passed to the deallocation operation. +One way to do this is to start containers on aligned addresses in memory, then truncate the lower bits of the object address to obtain the header address (or round up and subtract the trailer size to obtain the trailer address). +For example, if an object at address 0xFC28\,EF08 is freed and containers are aligned on 64\,KB (0x0001\,0000) addresses, then the container header is at 0xFC28\,0000. + +Normally, a container has homogeneous objects of fixed size, with fixed information in the header that applies to all container objects (\eg object size and ownership). +This approach greatly reduces internal fragmentation since far fewer headers are required, and potentially increases spatial locality as a cache line or page holds more objects since the objects are closer together due to the lack of headers. +However, although similar objects are close spatially within the same container, different sized objects are further apart in separate containers. +Depending on the program, this may or may not improve locality. +If the program uses several objects from a small number of containers in its working set, then locality is improved since fewer cache lines and pages are required. +If the program uses many containers, there is poor locality, as both caching and paging increase. +Another drawback is that external fragmentation may be increased since containers reserve space for objects that may never be allocated by the program, \ie there are often multiple containers for each size only partially full. +However, external fragmentation can be reduced by using small containers. + +Containers with heterogeneous objects implies different headers describing them, which complicates the problem of locating a specific header solely by an address. +A couple of solutions can be used to implement containers with heterogeneous objects. +However, the problem with allowing objects of different sizes is that the number of objects, and therefore headers, in a single container is unpredictable. +One solution allocates headers at one end of the container, while allocating objects from the other end of the container; +when the headers meet the objects, the container is full. +Freed objects cannot be split or coalesced since this causes the number of headers to change. +The difficulty in this strategy remains in finding the header for a specific object; +in general, a search is necessary to find the object's header among the container headers. +A second solution combines the use of container headers and individual object headers. +Each object header stores the object's heterogeneous information, such as its size, while the container header stores the homogeneous information, such as the owner when using ownership. +This approach allows containers to hold different types of objects, but does not completely separate headers from objects. +The benefit of the container in this case is to reduce some redundant information that is factored into the container header. + +In summary, object containers trade off internal fragmentation for external fragmentation by isolating common administration information to remove/reduce internal fragmentation, but at the cost of external fragmentation as some portion of a container may not be used and this portion is unusable for other kinds of allocations. +A consequence of this tradeoff is its effect on spatial locality, which can produce positive or negative results depending on program access-patterns. + + +\subsubsection{Container Ownership} +\label{s:ContainerOwnership} + +Without ownership, objects in a container are deallocated to the heap currently associated with the thread that frees the object. +Thus, different objects in a container may be on different heap free-lists (see \VRef[Figure]{f:ContainerNoOwnershipFreelist}). +With ownership, all objects in a container belong to the same heap (see \VRef[Figure]{f:ContainerOwnershipFreelist}), so ownership of an object is determined by the container owner. +If multiple threads can allocate/free/reallocate adjacent storage in the same heap, all forms of false sharing may occur. +Only with the 1:1 model and ownership is active and passive false-sharing avoided (see \VRef{s:Ownership}). +Passive false-sharing may still occur, if delayed ownership is used. + +\begin{figure} +\centering +\subfigure[No Ownership]{ + \input{ContainerNoOwnershipFreelist} + \label{f:ContainerNoOwnershipFreelist} +} % subfigure +\vrule +\subfigure[Ownership]{ + \input{ContainerOwnershipFreelist} + \label{f:ContainerOwnershipFreelist} +} % subfigure +\caption{Free-list Structure with Container Ownership} +\end{figure} + +A fragmented heap has multiple containers that may be partially or completely free. +A completely free container can become reserved storage and be reset to allocate objects of a new size. +When a heap reaches a threshold of free objects, it moves some free storage to the global heap for reuse to prevent heap blowup. +Without ownership, when a heap frees objects to the global heap, individual objects must be passed, and placed on the global-heap's free-list. +Containers cannot be freed to the global heap unless completely free because + +When a container changes ownership, the ownership of all objects within it change as well. +Moving a container involves moving all objects on the heap's free-list in that container to the new owner. +This approach can reduce contention for the global heap, since each request for objects from the global heap returns a container rather than individual objects. + +Additional restrictions may be applied to the movement of containers to prevent active false-sharing. +For example, in \VRef[Figure]{f:ContainerFalseSharing1}, a container being used by Task$_1$ changes ownership, through the global heap. +In \VRef[Figure]{f:ContainerFalseSharing2}, when Task$_2$ allocates an object from the newly acquired container it is actively false-sharing even though no objects are passed among threads. +Note, once the object is freed by Task$_1$, no more false sharing can occur until the container changes ownership again. +To prevent this form of false sharing, container movement may be restricted to when all objects in the container are free. +One implementation approach that increases the freedom to return a free container to the operating system involves allocating containers using a call like @mmap@, which allows memory at an arbitrary address to be returned versus only storage at the end of the contiguous @sbrk@ area. + +\begin{figure} +\centering +\subfigure[]{ + \input{ContainerFalseSharing1} + \label{f:ContainerFalseSharing1} +} % subfigure +\subfigure[]{ + \input{ContainerFalseSharing2} + \label{f:ContainerFalseSharing2} +} % subfigure +\caption{Active False-Sharing using Containers} +\label{f:ActiveFalseSharingContainers} +\end{figure} + +Using containers with ownership increases external fragmentation since a new container for a requested object size must be allocated separately for each thread requesting it. +In \VRef[Figure]{f:ExternalFragmentationContainerOwnership}, using object ownership allocates 80\% more space than without ownership. + +\begin{figure} +\centering +\subfigure[No Ownership]{ + \input{ContainerNoOwnership} +} % subfigure +\\ +\subfigure[Ownership]{ + \input{ContainerOwnership} +} % subfigure +\caption{External Fragmentation with Container Ownership} +\label{f:ExternalFragmentationContainerOwnership} +\end{figure} + + +\subsubsection{Container Size} +\label{s:ContainerSize} + +One way to control the external fragmentation caused by allocating a large container for a small number of requested objects is to vary the size of the container. +As described earlier, container boundaries need to be aligned on addresses that are a power of two to allow easy location of the header (by truncating lower bits). +Aligning containers in this manner also determines the size of the container. +However, the size of the container has different implications for the allocator. + +The larger the container, the fewer containers are needed, and hence, the fewer headers need to be maintained in memory, improving both internal fragmentation and potentially performance. +However, with more objects in a container, there may be more objects that are unallocated, increasing external fragmentation. +With smaller containers, not only are there more containers, but a second new problem arises where objects are larger than the container. +In general, large objects, \eg greater than 64\,KB, are allocated directly from the operating system and are returned immediately to the operating system to reduce long-term external fragmentation. +If the container size is small, \eg 1\,KB, then a 1.5\,KB object is treated as a large object, which is likely to be inappropriate. +Ideally, it is best to use smaller containers for smaller objects, and larger containers for medium objects, which leads to the issue of locating the container header. + +In order to find the container header when using different sized containers, a super container is used (see~\VRef[Figure]{f:SuperContainers}). +The super container spans several containers, contains a header with information for finding each container header, and starts on an aligned address. +Super-container headers are found using the same method used to find container headers by dropping the lower bits of an object address. +The containers within a super container may be different sizes or all the same size. +If the containers in the super container are different sizes, then the super-container header must be searched to determine the specific container for an object given its address. +If all containers in the super container are the same size, \eg 16KB, then a specific container header can be found by a simple calculation. +The free space at the end of a super container is used to allocate new containers. + +\begin{figure} +\centering +\input{SuperContainers} +% \includegraphics{diagrams/supercontainer.eps} +\caption{Super Containers} +\label{f:SuperContainers} +\end{figure} + +Minimal internal and external fragmentation is achieved by having as few containers as possible, each being as full as possible. +It is also possible to achieve additional benefit by using larger containers for popular small sizes, as it reduces the number of containers with associated headers. +However, this approach assumes it is possible for an allocator to determine in advance which sizes are popular. +Keeping statistics on requested sizes allows the allocator to make a dynamic decision about which sizes are popular. +For example, after receiving a number of allocation requests for a particular size, that size is considered a popular request size and larger containers are allocated for that size. +If the decision is incorrect, larger containers than necessary are allocated that remain mostly unused. +A programmer may be able to inform the allocator about popular object sizes, using a mechanism like @mallopt@, in order to select an appropriate container size for each object size. + + +\subsubsection{Container Free-Lists} +\label{s:containersfreelists} + +The container header allows an alternate approach for managing the heap's free-list. +Rather than maintain a global free-list throughout the heap (see~\VRef[Figure]{f:GlobalFreeListAmongContainers}), the containers are linked through their headers and only the local free objects within a container are linked together (see~\VRef[Figure]{f:LocalFreeListWithinContainers}). +Note, maintaining free lists within a container assumes all free objects in the container are associated with the same heap; +thus, this approach only applies to containers with ownership. + +This alternate free-list approach can greatly reduce the complexity of moving all freed objects belonging to a container to another heap. +To move a container using a global free-list, as in \VRef[Figure]{f:GlobalFreeListAmongContainers}, the free list is first searched to find all objects within the container. +Each object is then removed from the free list and linked together to form a local free-list for the move to the new heap. +With local free-lists in containers, as in \VRef[Figure]{f:LocalFreeListWithinContainers}, the container is simply removed from one heap's free list and placed on the new heap's free list. +Thus, when using local free-lists, the operation of moving containers is reduced from $O(N)$ to $O(1)$. +The cost is adding information to a header, which increases the header size, and therefore internal fragmentation. + +\begin{figure} +\centering +\subfigure[Global Free-List Among Containers]{ + \input{FreeListAmongContainers} + \label{f:GlobalFreeListAmongContainers} +} % subfigure +\hspace{0.25in} +\subfigure[Local Free-List Within Containers]{ + \input{FreeListWithinContainers} + \label{f:LocalFreeListWithinContainers} +} % subfigure +\caption{Container Free-List Structure} +\label{f:ContainerFreeListStructure} +\end{figure} + +When all objects in the container are the same size, a single free-list is sufficient. +However, when objects in the container are different size, the header needs a free list for each size class when using a binning allocation algorithm, which can be a significant increase in the container-header size. +The alternative is to use a different allocation algorithm with a single free-list, such as a sequential-fit allocation-algorithm. + + +\subsection{Hybrid Private/Public Heap} +\label{s:HybridPrivatePublicHeap} + +Section~\Vref{s:Ownership} discusses advantages and disadvantages of public heaps (T:H model and with ownership) and private heaps (thread heaps with ownership). +For thread heaps with ownership, it is possible to combine these approaches into a hybrid approach with both private and public heaps (see~\VRef[Figure]{f:HybridPrivatePublicHeap}). +The main goal of the hybrid approach is to eliminate locking on thread-local allocation/deallocation, while providing ownership to prevent heap blowup. +In the hybrid approach, a task first allocates from its private heap and second from its public heap if no free memory exists in the private heap. +Similarly, a task first deallocates an object its private heap, and second to the public heap. +Both private and public heaps can allocate/deallocate to/from the global heap if there is no free memory or excess free memory, although an implementation may choose to funnel all interaction with the global heap through one of the heaps. +Note, deallocation from the private to the public (dashed line) is unlikely because there is no obvious advantages unless the public heap provides the only interface to the global heap. +Finally, when a task frees an object it does not own, the object is either freed immediately to its owner's public heap or put in the freeing task's private heap for delayed ownership, which allows the freeing task to temporarily reuse an object before returning it to its owner or batch objects for an owner heap into a single return. + +\begin{figure} +\centering +\input{PrivatePublicHeaps.pstex_t} +\caption{Hybrid Private/Public Heap for Per-thread Heaps} +\label{f:HybridPrivatePublicHeap} +% \vspace{10pt} +% \input{RemoteFreeList.pstex_t} +% \caption{Remote Free-List} +% \label{f:RemoteFreeList} +\end{figure} + +As mentioned, an implementation may have only one heap deal with the global heap, so the other heap can be simplified. +For example, if only the private heap interacts with the global heap, the public heap can be reduced to a lock-protected free-list of objects deallocated by other threads due to ownership, called a \newterm{remote free-list}. +To avoid heap blowup, the private heap allocates from the remote free-list when it reaches some threshold or it has no free storage. +Since the remote free-list is occasionally cleared during an allocation, this adds to that cost. +Clearing the remote free-list is $O(1)$ if the list can simply be added to the end of the private-heap's free-list, or $O(N)$ if some action must be performed for each freed object. + +If only the public heap interacts with other threads and the global heap, the private heap can handle thread-local allocations and deallocations without locking. +In this scenario, the private heap must deallocate storage after reaching a certain threshold to the public heap (and then eventually to the global heap from the public heap) or heap blowup can occur. +If the public heap does the major management, the private heap can be simplified to provide high-performance thread-local allocations and deallocations. + +The main disadvantage of each thread having both a private and public heap is the complexity of managing two heaps and their interactions in an allocator. +Interestingly, heap implementations often focus on either a private or public heap, giving the impression a single versus a hybrid approach is being used. +In many case, the hybrid approach is actually being used, but the simpler heap is just folded into the complex heap, even though the operations logically belong in separate heaps. +For example, a remote free-list is actually a simple public-heap, but may be implemented as an integral component of the complex private-heap in an allocator, masking the presence of a hybrid approach. + + +\subsection{Allocation Buffer} +\label{s:AllocationBuffer} + +An allocation buffer is reserved memory (see~\VRef{s:AllocatorComponents}) not yet allocated to the program, and is used for allocating objects when the free list is empty. +That is, rather than requesting new storage for a single object, an entire buffer is requested from which multiple objects are allocated later. +Both any heap may use an allocation buffer, resulting in allocation from the buffer before requesting objects (containers) from the global heap or operating system, respectively. +The allocation buffer reduces contention and the number of global/operating-system calls. +For coalescing, a buffer is split into smaller objects by allocations, and recomposed into larger buffer areas during deallocations. + +Allocation buffers are useful initially when there are no freed objects in a heap because many allocations usually occur when a thread starts. +Furthermore, to prevent heap blowup, objects should be reused before allocating a new allocation buffer. +Thus, allocation buffers are often allocated more frequently at program/thread start, and then their use often diminishes. + +Using an allocation buffer with a thread heap avoids active false-sharing, since all objects in the allocation buffer are allocated to the same thread. +For example, if all objects sharing a cache line come from the same allocation buffer, then these objects are allocated to the same thread, avoiding active false-sharing. +Active false-sharing may still occur if objects are freed to the global heap and reused by another heap. + +Allocation buffers may increase external fragmentation, since some memory in the allocation buffer may never be allocated. +A smaller allocation buffer reduces the amount of external fragmentation, but increases the number of calls to the global heap or operating system. +The allocation buffer also slightly increases internal fragmentation, since a pointer is necessary to locate the next free object in the buffer. + +The unused part of a container, neither allocated or freed, is an allocation buffer. +For example, when a container is created, rather than placing all objects within the container on the free list, the objects form an allocation buffer and are allocated from the buffer as allocation requests are made. +This lazy method of constructing objects is beneficial in terms of paging and caching. +For example, although an entire container, possibly spanning several pages, is allocated from the operating system, only a small part of the container is used in the working set of the allocator, reducing the number of pages and cache lines that are brought into higher levels of cache. + + +\subsection{Lock-Free Operations} +\label{s:LockFreeOperations} + +A lock-free algorithm guarantees safe concurrent-access to a data structure, so that at least one thread can make progress in the system, but an individual task has no bound to execution, and hence, may starve~\cite[pp.~745--746]{Herlihy93}. +% A wait-free algorithm puts a finite bound on the number of steps any thread takes to complete an operation, so an individual task cannot starve +Lock-free operations can be used in an allocator to reduce or eliminate the use of locks. +Locks are a problem for high contention or if the thread holding the lock is preempted and other threads attempt to use that lock. +With respect to the heap, these situations are unlikely unless all threads makes extremely high use of dynamic-memory allocation, which can be an indication of poor design. +Nevertheless, lock-free algorithms can reduce the number of context switches, since a thread does not yield/block while waiting for a lock; +on the other hand, a thread may busy-wait for an unbounded period. +Finally, lock-free implementations have greater complexity and hardware dependency. +Lock-free algorithms can be applied most easily to simple free-lists, \eg remote free-list, to allow lock-free insertion and removal from the head of a stack. +Implementing lock-free operations for more complex data-structures (queue~\cite{Valois94}/deque~\cite{Sundell08}) is more complex. +Michael~\cite{Michael04} and Gidenstam \etal \cite{Gidenstam05} have created lock-free variations of the Hoard allocator. + \noindent Index: doc/theses/mubeen_zulfiqar_MMath/figures/AddressSpace.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AddressSpace.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AddressSpace.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,48 @@ +#FIG 3.2 Produced by xfig version 3.2.7b +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5700 1350 6600 1350 6600 2100 5700 2100 5700 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1350 2100 1350 2100 2100 1200 2100 1200 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4800 1350 5700 1350 5700 2100 4800 2100 4800 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2100 1725 2400 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3000 1725 2700 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3900 1725 4200 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4800 1725 4500 1725 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 2100 1350 3000 1350 3000 2100 2100 2100 2100 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1350 3900 1350 3900 2100 3000 2100 3000 1350 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3900 1350 4800 1350 4800 2100 3900 2100 3900 1350 +4 0 0 50 -1 0 11 0.0000 2 180 900 1200 2325 high address\001 +4 2 0 50 -1 0 11 0.0000 2 135 855 6600 2325 low address\001 +4 1 0 50 -1 0 11 0.0000 2 120 330 6150 2025 Data\001 +4 1 0 50 -1 0 11 0.0000 2 135 675 6150 1800 Code and\001 +4 1 0 50 -1 0 11 0.0000 2 120 390 6150 1575 Static\001 +4 1 0 50 -1 0 11 0.0000 2 135 390 1650 1800 Stack\001 +4 1 0 50 -1 0 11 0.0000 2 165 615 2550 1950 Memory\001 +4 1 0 50 -1 0 11 0.0000 2 165 615 4350 1950 Memory\001 +4 1 0 50 -1 0 11 0.0000 2 120 315 2550 1650 Free\001 +4 1 0 50 -1 0 11 0.0000 2 120 330 3450 2025 Data\001 +4 1 0 50 -1 0 11 0.0000 2 135 675 3450 1800 Code and\001 +4 1 0 50 -1 0 11 0.0000 2 165 645 3450 1575 Dynamic\001 +4 1 0 50 -1 0 11 0.0000 2 120 315 4350 1650 Free\001 +4 1 0 50 -1 0 11 0.0000 2 120 735 5250 1950 Allocation\001 +4 1 0 50 -1 0 11 0.0000 2 165 645 5250 1650 Dynamic\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/AllocDS1.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AllocDS1.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AllocDS1.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,162 @@ +#FIG 3.2 Produced by xfig version 3.2.7b +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 4200 1575 4500 1725 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4275 1650 20 20 4275 1650 4295 1650 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4350 1650 20 20 4350 1650 4370 1650 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4425 1650 20 20 4425 1650 4445 1650 +-6 +6 2850 2475 3150 2850 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2925 2475 2925 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2850 2700 3150 2700 3150 2850 2850 2850 2850 2700 +-6 +6 4350 2475 4650 2850 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4425 2475 4425 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4350 2700 4650 2700 4650 2850 4350 2850 4350 2700 +-6 +6 3600 2475 3825 3150 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3675 2475 3675 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 2700 3825 2700 3825 2850 3600 2850 3600 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 3000 3825 3000 3825 3150 3600 3150 3600 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3675 2775 3675 3000 +-6 +6 4875 3600 5175 3750 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4950 3675 20 20 4950 3675 4970 3675 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5025 3675 20 20 5025 3675 5045 3675 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5100 3675 20 20 5100 3675 5120 3675 +-6 +6 4875 2325 5175 2475 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4950 2400 20 20 4950 2400 4970 2400 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5025 2400 20 20 5025 2400 5045 2400 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5100 2400 20 20 5100 2400 5120 2400 +-6 +6 5625 2325 5925 2475 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5700 2400 20 20 5700 2400 5720 2400 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5775 2400 20 20 5775 2400 5795 2400 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5850 2400 20 20 5850 2400 5870 2400 +-6 +6 5625 3600 5925 3750 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5700 3675 20 20 5700 3675 5720 3675 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5775 3675 20 20 5775 3675 5795 3675 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5850 3675 20 20 5850 3675 5870 3675 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2400 2100 2400 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2550 2100 2550 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2700 2100 2700 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2850 2100 2850 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3000 2100 3000 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3600 2100 3600 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3900 2100 3900 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4050 2100 4050 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4200 2100 4200 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4350 2100 4350 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 2100 4500 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3300 1500 3300 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3600 1500 3600 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3900 1500 3900 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1500 4800 1500 4800 1800 3000 1800 3000 1500 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3225 1650 2625 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3150 1650 2550 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3450 1650 4050 2100 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3375 1650 3975 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2100 2100 2100 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 2250 3150 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3450 2250 4650 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1950 2100 3150 2100 3150 2550 1950 2550 1950 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3450 2100 4650 2100 4650 2550 3450 2550 3450 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2250 2100 2250 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3750 2100 3750 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2025 2475 2025 2700 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2025 2775 2025 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1950 3000 2100 3000 2100 3150 1950 3150 1950 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1950 2700 2100 2700 2100 2850 1950 2850 1950 2700 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 1950 3750 2700 3750 2700 3525 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1950 3525 3150 3525 3150 3900 1950 3900 1950 3525 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 3450 3750 4200 3750 4200 3525 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3450 3525 4650 3525 4650 3900 3450 3900 3450 3525 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 3150 4650 4200 4650 4200 4275 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3150 4275 4650 4275 4650 4875 3150 4875 3150 4275 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 2400 3150 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3450 2400 4650 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5400 2100 5400 3900 +4 2 0 50 -1 0 11 0.0000 2 120 300 1875 2250 lock\001 +4 1 0 50 -1 0 12 0.0000 2 135 1935 3900 1425 N kernel-thread buckets\001 +4 1 0 50 -1 0 12 0.0000 2 195 810 4425 2025 heap$_2$\001 +4 1 0 50 -1 0 12 0.0000 2 195 810 2175 2025 heap$_1$\001 +4 2 0 50 -1 0 11 0.0000 2 120 270 1875 2400 size\001 +4 2 0 50 -1 0 11 0.0000 2 120 270 1875 2550 free\001 +4 1 0 50 -1 0 12 0.0000 2 180 825 2550 3450 local pool\001 +4 0 0 50 -1 0 12 0.0000 2 135 360 3525 3700 lock\001 +4 0 0 50 -1 0 12 0.0000 2 135 360 3225 4450 lock\001 +4 2 0 50 -1 0 12 0.0000 2 135 600 1875 3000 free list\001 +4 1 0 50 -1 0 12 0.0000 2 180 825 4050 3450 local pool\001 +4 1 0 50 -1 0 12 0.0000 2 180 1455 3900 4200 global pool (sbrk)\001 +4 0 0 50 -1 0 12 0.0000 2 135 360 2025 3700 lock\001 +4 1 0 50 -1 0 12 0.0000 2 180 720 6450 3150 free pool\001 +4 1 0 50 -1 0 12 0.0000 2 180 390 6450 2925 heap\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/AllocDS2.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AllocDS2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AllocDS2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,126 @@ +#FIG 3.2 Produced by xfig version 3.2.7b +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2850 2100 3150 2250 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 2925 2175 20 20 2925 2175 2945 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3000 2175 20 20 3000 2175 3020 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3075 2175 20 20 3075 2175 3095 2175 +-6 +6 4050 2100 4350 2250 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4125 2175 20 20 4125 2175 4145 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4200 2175 20 20 4200 2175 4220 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4275 2175 20 20 4275 2175 4295 2175 +-6 +6 4650 2100 4950 2250 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4725 2175 20 20 4725 2175 4745 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4800 2175 20 20 4800 2175 4820 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4875 2175 20 20 4875 2175 4895 2175 +-6 +6 3450 2100 3750 2250 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3525 2175 20 20 3525 2175 3545 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3600 2175 20 20 3600 2175 3620 2175 +1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3675 2175 20 20 3675 2175 3695 2175 +-6 +6 3300 2175 3600 2550 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3375 2175 3375 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 2400 3600 2400 3600 2550 3300 2550 3300 2400 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3150 1800 3150 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2850 1800 2850 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4650 1800 4650 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4950 1800 4950 2250 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 1725 4500 2250 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5100 1725 5100 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3450 1800 3450 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3750 1800 3750 2250 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3300 1725 3300 2250 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3900 1725 3900 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5250 1800 5250 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5400 1800 5400 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5550 1800 5550 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5700 1800 5700 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5850 1800 5850 2250 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2700 1725 2700 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3375 1275 3375 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 1275 2700 1575 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2775 1275 2775 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5175 1275 5175 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5625 1275 5625 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3750 1275 3750 1575 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3825 1275 3825 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2700 1950 6000 1950 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2700 2100 6000 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1800 6000 1800 6000 2250 2700 2250 2700 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2775 2175 2775 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2775 2475 2775 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 2700 2850 2700 2850 2850 2700 2850 2700 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 2400 2850 2400 2850 2550 2700 2550 2700 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4575 2175 4575 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 2400 5025 2400 5025 2550 4500 2550 4500 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 3600 3525 4650 3525 4650 3150 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 3150 5100 3150 5100 3750 3600 3750 3600 3150 +4 2 0 50 -1 0 11 0.0000 2 120 300 2625 1950 lock\001 +4 1 0 50 -1 0 10 0.0000 2 150 1155 3000 1725 N$\\times$S$_1$\001 +4 1 0 50 -1 0 10 0.0000 2 150 1155 3600 1725 N$\\times$S$_2$\001 +4 1 0 50 -1 0 12 0.0000 2 180 390 4425 1500 heap\001 +4 2 0 50 -1 0 12 0.0000 2 135 1140 2550 1425 kernel threads\001 +4 2 0 50 -1 0 11 0.0000 2 120 270 2625 2100 size\001 +4 2 0 50 -1 0 11 0.0000 2 120 270 2625 2250 free\001 +4 2 0 50 -1 0 12 0.0000 2 135 600 2625 2700 free list\001 +4 0 0 50 -1 0 12 0.0000 2 135 360 3675 3325 lock\001 +4 1 0 50 -1 0 12 0.0000 2 180 1455 4350 3075 global pool (sbrk)\001 +4 1 0 50 -1 0 10 0.0000 2 150 1110 4800 1725 N$\\times$S$_t$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/AllocInducedActiveFalseSharing.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AllocInducedActiveFalseSharing.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AllocInducedActiveFalseSharing.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,54 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2250 2400 4050 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2250 2400 3150 2400 3150 2700 2250 2700 2250 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3150 2400 4050 2400 4050 2700 3150 2700 3150 2400 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 2625 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3600 2625 Object$_2$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1050 1500 1950 1500 1950 1800 1050 1800 1050 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 900 3000 900 3000 1950 900 1950 900 900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1950 1950 2700 2400 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 1950 1500 2850 1500 2850 1800 1950 1800 1950 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4350 1500 5250 1500 5250 1800 4350 1800 4350 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 900 5400 900 5400 1950 3300 1950 3300 900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4350 1950 3600 2400 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3450 1500 4350 1500 4350 1800 3450 1800 3450 1500 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 2850 1200 2850 975 2250 975 2250 1200 2850 1200 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 5250 1200 5250 975 4650 975 4650 1200 5250 1200 +4 1 0 50 -1 0 11 0.0000 2 195 735 2550 1125 Task$_1$\001 +4 0 0 50 -1 0 11 0.0000 2 195 720 975 1125 CPU$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 135 480 1950 1425 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1500 1725 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2400 1725 Object$_2$\001 +4 2 0 50 -1 2 11 0.0000 2 135 585 2250 2250 1. alloc\001 +4 1 0 50 -1 0 11 0.0000 2 195 735 4950 1125 Task$_2$\001 +4 0 0 50 -1 0 11 0.0000 2 195 720 3375 1125 CPU$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 1725 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4800 1725 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 135 480 4350 1425 Cache\001 +4 2 0 50 -1 0 11 0.0000 2 180 630 2175 2625 Memory\001 +4 0 0 50 -1 2 11 0.0000 2 180 720 4050 2250 4. modify\001 +4 2 0 50 -1 2 11 0.0000 2 135 585 3900 2175 3. alloc\001 +4 0 0 50 -1 2 11 0.0000 2 180 720 2400 2175 2. modify\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/AllocInducedPassiveFalseSharing.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AllocInducedPassiveFalseSharing.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AllocInducedPassiveFalseSharing.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,58 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 3750.000 4062.500 2550 975 3750 750 4950 975 + 1 1 1.00 45.00 90.00 +6 2250 2400 4050 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2250 2400 3150 2400 3150 2700 2250 2700 2250 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3150 2400 4050 2400 4050 2700 3150 2700 3150 2400 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 2625 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3600 2625 Object$_2$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1050 1500 1950 1500 1950 1800 1050 1800 1050 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 900 3000 900 3000 1950 900 1950 900 900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1950 1950 2700 2400 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 1950 1500 2850 1500 2850 1800 1950 1800 1950 1500 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3450 1500 4350 1500 4350 1800 3450 1800 3450 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4350 1500 5250 1500 5250 1800 4350 1800 4350 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 900 5400 900 5400 1950 3300 1950 3300 900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4350 1950 3600 2400 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 5250 1200 5250 975 4650 975 4650 1200 5250 1200 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 2850 1200 2850 975 2250 975 2250 1200 2850 1200 +4 1 0 50 -1 0 11 0.0000 2 195 735 2550 1125 Task$_1$\001 +4 0 0 50 -1 0 11 0.0000 2 195 720 975 1125 CPU$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 135 480 1950 1425 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1500 1725 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2400 1725 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 735 4950 1125 Task$_2$\001 +4 0 0 50 -1 0 11 0.0000 2 195 720 3375 1125 CPU$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 1725 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4800 1725 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 135 480 4350 1425 Cache\001 +4 0 0 50 -1 2 11 0.0000 2 180 720 4050 2250 6. modify\001 +4 2 0 50 -1 0 11 0.0000 2 180 630 2175 2625 Memory\001 +4 2 0 50 -1 2 11 0.0000 2 135 585 2250 2250 1. alloc\001 +4 0 0 50 -1 2 11 0.0000 2 180 720 2400 2175 3. modify\001 +4 2 0 50 -1 2 11 0.0000 2 135 585 3675 2325 5. alloc\001 +4 2 0 50 -1 2 11 0.0000 2 135 780 3975 2175 4. dealloc\001 +4 1 0 50 -1 2 11 0.0000 2 195 2400 3750 675 2. pass Object$_2$ reference\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/AllocatedObject.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AllocatedObject.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AllocatedObject.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,28 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3900 1200 4800 1200 4800 1500 3900 1500 3900 1200 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 2100 1200 3000 1200 3000 1500 2100 1500 2100 1200 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 5700 1200 5700 1500 1200 1500 1200 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2100 1200 2100 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3000 1200 3000 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3900 1200 3900 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4800 1200 4800 1500 +4 1 0 50 -1 0 11 0.0000 2 135 555 1650 1425 Header\001 +4 1 0 50 -1 0 11 0.0000 2 180 600 2550 1425 Padding\001 +4 1 0 50 -1 0 11 0.0000 2 180 510 3450 1425 Object\001 +4 1 0 50 -1 0 11 0.0000 2 180 600 4350 1425 Spacing\001 +4 1 0 50 -1 0 11 0.0000 2 135 495 5250 1425 Trailer\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/AllocatorComponents.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/AllocatorComponents.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/AllocatorComponents.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,97 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2325 2775 3000 3150 +4 2 0 50 -1 0 11 0.0000 2 135 660 3000 2925 reserved\001 +4 2 0 50 -1 0 11 0.0000 2 135 600 3000 3075 memory\001 +-6 +6 2400 1575 3000 1950 +4 2 0 50 -1 0 11 0.0000 2 180 555 3000 1875 objects\001 +4 2 0 50 -1 0 11 0.0000 2 135 300 3000 1725 free\001 +-6 +6 2400 2100 2700 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 2400 2700 2700 2400 2700 2400 2400 2700 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 2100 2700 2400 2400 2400 2400 2100 2700 2100 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4200 1800 4800 1800 4800 2100 4200 2100 4200 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4200 2100 5100 2100 5100 2400 4200 2400 4200 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5100 2100 6300 2100 6300 2400 5100 2400 5100 2100 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3300 1800 4200 1800 4200 2100 3300 2100 3300 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 5400 1800 6300 1800 6300 2100 5400 2100 5400 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3300 2100 3600 2100 3600 2400 3300 2400 3300 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 2400 3900 2400 3900 2700 3300 2700 3300 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 2400 4800 2400 4800 2700 3900 2700 3900 2400 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 4800 2400 5400 2400 5400 2700 4800 2700 4800 2400 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 4800 1800 5400 1800 5400 2100 4800 2100 4800 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5400 2400 6300 2400 6300 2700 5400 2700 5400 2400 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 3300 2700 6300 2700 6300 3300 3300 3300 3300 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 3300 3600 3300 3600 3600 3300 3600 3300 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 3300 5100 3300 5100 3600 4500 3600 4500 3300 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 5100 3300 6300 3300 6300 3600 5100 3600 5100 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 3600 4500 3600 4500 3900 3300 3900 3300 3600 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 3600 5400 3600 5400 3900 4500 3900 4500 3600 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5400 3600 6300 3600 6300 3900 5400 3900 5400 3600 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 3900 3900 3900 3900 4200 3300 4200 3300 3900 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 5100 3900 5700 3900 5700 4200 5100 4200 5100 3900 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 3900 5100 3900 5100 4200 3900 4200 3900 3900 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5700 3900 6300 3900 6300 4200 5700 4200 5700 3900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3750 1950 4800 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5100 1950 3300 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3450 2250 4800 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5100 2550 5400 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5850 1950 5100 3300 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5700 3450 5100 3900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 2250 3300 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 2550 3300 2700 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3150 1275 3150 4200 +4 1 0 50 -1 0 11 0.0000 2 135 885 2325 1425 Static Zone\001 +4 1 0 50 -1 0 11 0.0000 2 180 1950 4800 1425 Dynamic-Allocation Zone\001 +4 0 0 50 -1 2 11 0.0000 2 180 645 3300 1725 Storage\001 +4 2 0 50 -1 2 11 0.0000 2 180 1050 2325 2475 Management\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/CoalesceAllocated.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/CoalesceAllocated.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/CoalesceAllocated.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,24 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2100 1200 2100 1500 1200 1500 1200 1200 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1200 3000 1200 3000 1500 2100 1500 2100 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1200 3900 1200 3900 1500 3000 1500 3000 1200 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3900 1200 4800 1200 4800 1500 3900 1500 3900 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 2550 1200 2550 1050 1800 1050 +4 1 0 50 -1 0 11 0.0000 2 180 510 3450 1425 Object\001 +4 1 0 50 -1 0 11 0.0000 2 135 330 1650 1425 Size\001 +4 1 0 50 -1 0 11 0.0000 2 135 510 2550 1425 Owner\001 +4 1 0 50 -1 0 11 0.0000 2 195 780 4350 1425 $\\pm$Size\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/CoalesceFree.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/CoalesceFree.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/CoalesceFree.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,27 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3900 1200 4800 1200 4800 1500 3900 1500 3900 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2100 1200 2100 1500 1200 1500 1200 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 2550 1200 2550 1050 1800 1050 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 45.00 90.00 + 3450 1200 3450 1050 4200 1050 +2 2 0 1 0 7 60 -1 18 0.000 0 0 -1 0 0 5 + 3000 1200 3900 1200 3900 1500 3000 1500 3000 1200 +2 2 0 1 0 7 60 -1 18 0.000 0 0 -1 0 0 5 + 2100 1200 3000 1200 3000 1500 2100 1500 2100 1200 +4 1 0 50 -1 0 11 0.0000 2 195 780 4350 1425 $\\pm$Size\001 +4 1 0 50 -1 0 11 0.0000 2 135 330 1650 1425 Size\001 +4 1 0 50 -1 0 11 0.0000 2 135 660 2550 1425 Previous\001 +4 1 0 50 -1 0 11 0.0000 2 135 375 3450 1425 Next\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/Container.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/Container.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/Container.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,29 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1200 1125 2100 1575 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1275 1200 2025 1200 2025 1500 1275 1500 1275 1200 +4 1 0 50 -1 0 11 0.0000 2 135 555 1650 1425 Header\001 +-6 +6 1950 1125 2850 1575 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2025 1200 2775 1200 2775 1500 2025 1500 2025 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 2400 1425 Object$_1$\001 +-6 +6 2700 1125 3600 1575 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2775 1200 3525 1200 3525 1500 2775 1500 2775 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 3150 1425 Object$_2$\001 +-6 +6 3450 1125 4350 1575 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3525 1200 4275 1200 4275 1500 3525 1500 3525 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 1425 Object$_3$\001 +-6 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContainerFalseSharing1.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContainerFalseSharing1.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContainerFalseSharing1.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,48 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 2100.000 1762.500 1800 1200 2100 1125 2400 1200 + 1 1 1.00 45.00 90.00 +6 1050 1200 1950 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 1800 1200 1800 1500 1200 1500 1200 1200 +4 1 0 50 -1 0 11 0.0000 2 195 765 1500 1425 Heap$_1$\001 +-6 +6 2250 1200 3150 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1200 3000 1200 3000 1500 2400 1500 2400 1200 +4 1 0 50 -1 0 11 0.0000 2 195 765 2700 1425 Heap$_2$\001 +-6 +6 1200 1950 3000 2250 +6 1200 1950 1800 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1950 1800 1950 1800 2250 1200 2250 1200 1950 +4 1 0 50 -1 0 11 0.0000 2 135 555 1500 2175 Header\001 +-6 +6 1650 1950 2550 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1950 2400 1950 2400 2250 1800 2250 1800 1950 +4 1 0 50 -1 0 11 0.0000 2 195 870 2100 2175 Object$_1$\001 +-6 +6 2400 1950 3000 2250 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 2400 1950 3000 1950 3000 2250 2400 2250 2400 1950 +4 1 0 50 -1 0 11 0.0000 2 135 345 2700 2175 Free\001 +-6 +-6 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 4 + 1 1 1.00 45.00 90.00 + 1200 1350 1050 1350 1050 2100 1200 2100 +2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 1500 2100 1950 +4 2 0 50 -1 0 11 0.0000 2 90 315 975 1875 own\001 +4 0 0 50 -1 0 11 0.0000 2 180 510 1950 1725 modify\001 +4 1 0 50 -1 0 11 0.0000 2 180 2370 1875 825 pass object container indirectly\001 +4 1 0 50 -1 0 11 0.0000 2 180 1410 2025 1050 via the global heap\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContainerFalseSharing2.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContainerFalseSharing2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContainerFalseSharing2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,48 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1050 1200 1950 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 1800 1200 1800 1500 1200 1500 1200 1200 +4 1 0 50 -1 0 11 0.0000 2 195 765 1500 1425 Heap$_1$\001 +-6 +6 2250 1200 3150 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1200 3000 1200 3000 1500 2400 1500 2400 1200 +4 1 0 50 -1 0 11 0.0000 2 195 765 2700 1425 Heap$_2$\001 +-6 +6 1200 1950 3150 2250 +6 1200 1950 1800 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1950 1800 1950 1800 2250 1200 2250 1200 1950 +4 1 0 50 -1 0 11 0.0000 2 135 555 1500 2175 Header\001 +-6 +6 1650 1950 2550 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1950 2400 1950 2400 2250 1800 2250 1800 1950 +4 1 0 50 -1 0 11 0.0000 2 195 870 2100 2175 Object$_1$\001 +-6 +6 2250 1950 3150 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1950 3000 1950 3000 2250 2400 2250 2400 1950 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 2175 Object$_2$\001 +-6 +-6 +2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 1500 2100 1950 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 4 + 1 1 1.00 45.00 90.00 + 3000 1350 3150 1350 3150 2100 3000 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1500 2550 1950 +4 0 0 50 -1 0 11 0.0000 2 180 510 1950 1725 modify\001 +4 0 0 50 -1 0 11 0.0000 2 135 360 2625 1725 alloc\001 +4 0 0 50 -1 0 11 0.0000 2 90 315 3225 1725 own\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContainerNoOwnership.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContainerNoOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContainerNoOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,56 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1350 1200 1950 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 1200 1950 1200 1950 1500 1350 1500 1350 1200 +4 1 0 50 -1 0 11 0.0000 2 135 555 1650 1425 Header\001 +-6 +6 1800 1800 2700 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1950 1800 2550 1800 2550 2100 1950 2100 1950 1800 +4 1 0 50 -1 0 11 0.0000 2 195 765 2250 2025 Heap$_1$\001 +-6 +6 1800 1200 2700 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1950 1200 2550 1200 2550 1500 1950 1500 1950 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 2250 1425 Object$_1$\001 +-6 +6 2400 1200 3300 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2550 1200 3150 1200 3150 1500 2550 1500 2550 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 2850 1425 Object$_2$\001 +-6 +6 3000 1200 3900 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3150 1200 3750 1200 3750 1500 3150 1500 3150 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 3450 1425 Object$_3$\001 +-6 +6 2700 1800 3600 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2850 1800 3450 1800 3450 2100 2850 2100 2850 1800 +4 1 0 50 -1 0 11 0.0000 2 195 765 3150 2025 Heap$_2$\001 +-6 +6 3750 1200 4350 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3750 1200 4350 1200 4350 1500 3750 1500 3750 1200 +4 1 0 50 -1 0 11 0.0000 2 135 345 4050 1425 Free\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1950 1800 1950 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1800 2550 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2850 1800 2550 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3450 1800 3750 1500 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContainerNoOwnershipFreelist.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContainerNoOwnershipFreelist.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContainerNoOwnershipFreelist.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,68 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1425 2400 1425 2400 1650 2100 1650 2100 1425 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3075 1425 3375 1425 3375 1650 3075 1650 3075 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 1425 2100 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2175 1500 2100 2325 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3150 1500 3075 2325 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2175 3450 3075 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3150 2400 2475 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2175 2400 3075 3375 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 1275 1650 1275 1650 1575 1350 1575 1350 1275 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 1950 1350 2850 1350 2850 1800 1950 1800 1950 1350 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 3000 1350 3900 1350 3900 1800 3000 1800 3000 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1200 4050 1200 4050 1950 1800 1950 1800 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3075 3375 3375 3375 3375 3600 3075 3600 3075 3375 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 3375 2400 3375 2400 3600 2100 3600 2100 3375 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 3225 1650 3225 1650 3525 1350 3525 1350 3225 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 3375 2100 3375 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 1950 3300 2850 3300 2850 3750 1950 3750 1950 3300 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 3000 3300 3900 3300 3900 3750 3000 3750 3000 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 3150 4050 3150 4050 3900 1800 3900 1800 3150 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2325 2400 2325 2400 2550 2100 2550 2100 2325 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3075 2325 3375 2325 3375 2550 3075 2550 3075 2325 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 1950 2250 2850 2250 2850 2700 1950 2700 1950 2250 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 3000 2250 3900 2250 3900 2700 3000 2700 3000 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 2100 4050 2100 4050 2850 1800 2850 1800 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2475 3375 2775 3375 2775 3600 2475 3600 2475 3375 +4 1 0 50 -1 0 11 0.0000 2 195 495 1500 1500 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 1500 3450 H$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContainerOwnership.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContainerOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContainerOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,81 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1200 1200 1800 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 1800 1200 1800 1500 1200 1500 1200 1200 +4 1 0 50 -1 0 11 0.0000 2 135 555 1500 1425 Header\001 +-6 +6 1650 1200 2550 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1200 2400 1200 2400 1500 1800 1500 1800 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 2100 1425 Object$_1$\001 +-6 +6 1650 1800 2550 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1800 2400 1800 2400 2100 1800 2100 1800 1800 +4 1 0 50 -1 0 11 0.0000 2 195 765 2100 2025 Heap$_1$\001 +-6 +6 2400 1200 3000 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 2400 1200 3000 1200 3000 1500 2400 1500 2400 1200 +4 1 0 50 -1 0 11 0.0000 2 135 345 2700 1425 Free\001 +-6 +6 3000 1200 3600 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 1200 3600 1200 3600 1500 3000 1500 3000 1200 +4 1 0 50 -1 0 11 0.0000 2 135 345 3300 1425 Free\001 +-6 +6 4500 1200 5100 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 1200 5100 1200 5100 1500 4500 1500 4500 1200 +4 1 0 50 -1 0 11 0.0000 2 135 555 4800 1425 Header\001 +-6 +6 4950 1200 5850 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5100 1200 5700 1200 5700 1500 5100 1500 5100 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 5400 1425 Object$_2$\001 +-6 +6 5550 1200 6450 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5700 1200 6300 1200 6300 1500 5700 1500 5700 1200 +4 1 0 50 -1 0 11 0.0000 2 195 870 6000 1425 Object$_3$\001 +-6 +6 6300 1200 6900 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 6300 1200 6900 1200 6900 1500 6300 1500 6300 1200 +4 1 0 50 -1 0 11 0.0000 2 135 345 6600 1425 Free\001 +-6 +6 5250 1800 6150 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5400 1800 6000 1800 6000 2100 5400 2100 5400 1800 +4 1 0 50 -1 0 11 0.0000 2 195 765 5700 2025 Heap$_2$\001 +-6 +6 3600 1200 4200 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3600 1200 4200 1200 4200 1500 3600 1500 3600 1200 +4 1 0 50 -1 0 11 0.0000 2 135 345 3900 1425 Free\001 +-6 +6 6900 1200 7500 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 6900 1200 7500 1200 7500 1500 6900 1500 6900 1200 +4 1 0 50 -1 0 11 0.0000 2 135 345 7200 1425 Free\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1800 1800 1800 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2400 1800 2400 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5400 1800 5100 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 6000 1800 6300 1500 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContainerOwnershipFreelist.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContainerOwnershipFreelist.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContainerOwnershipFreelist.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,63 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1425 2400 1425 2400 1650 2100 1650 2100 1425 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3075 1425 3375 1425 3375 1650 3075 1650 3075 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 1425 2100 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2175 1500 2100 2325 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2175 2400 3075 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3150 1500 3075 2325 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 1275 1650 1275 1650 1575 1350 1575 1350 1275 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 1950 1350 2850 1350 2850 1800 1950 1800 1950 1350 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 3000 1350 3900 1350 3900 1800 3000 1800 3000 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1200 4050 1200 4050 1950 1800 1950 1800 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 3375 2400 3375 2400 3600 2100 3600 2100 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 3375 2100 3375 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 3225 1650 3225 1650 3525 1350 3525 1350 3225 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3150 3375 3450 3375 3450 3600 3150 3600 3150 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2175 3450 3150 3375 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 1950 3300 2850 3300 2850 3750 1950 3750 1950 3300 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 3000 3300 3900 3300 3900 3750 3000 3750 3000 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 3150 4050 3150 4050 3900 1800 3900 1800 3150 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3075 2325 3375 2325 3375 2550 3075 2550 3075 2325 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2325 2400 2325 2400 2550 2100 2550 2100 2325 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 1950 2250 2850 2250 2850 2700 1950 2700 1950 2250 +2 2 1 1 0 7 50 -1 -1 6.000 0 0 -1 0 0 5 + 3000 2250 3900 2250 3900 2700 3000 2700 3000 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 2100 4050 2100 4050 2850 1800 2850 1800 2100 +4 1 0 50 -1 0 11 0.0000 2 195 495 1500 1500 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 1500 3450 H$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ContigFragmentation.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ContigFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ContigFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,22 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 1500 1800 1500 1800 1800 900 1800 900 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1500 2400 1500 2400 1800 1800 1800 1800 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1500 3000 1500 3000 1800 2400 1800 2400 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 1800 1500 1800 1500 2100 900 2100 900 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1500 1800 2700 1800 2700 2100 1500 2100 1500 1800 +2 3 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 7 + 900 2400 3000 2400 3000 1800 2700 1800 2700 2100 900 2100 + 900 2400 Index: doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingA.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingA.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingA.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,30 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2325 1500 2325 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2625 1500 3225 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1200 3750 1200 3750 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1200 2850 1200 2850 1500 2100 1500 2100 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2100 2850 2100 2850 2400 2100 2400 2100 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2850 2100 3600 2100 3600 2400 2850 2400 2850 2100 +4 2 0 50 -1 0 11 0.0000 2 150 405 2250 1875 alloc\001 +4 0 0 50 -1 0 11 0.0000 2 150 405 3075 1875 alloc\001 +4 2 0 50 -1 0 11 0.0000 2 150 570 1950 2325 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 210 855 2475 1425 Task$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 210 855 3375 1425 Task$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 210 1005 2475 2325 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 210 1005 3225 2325 Object$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingB.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingB.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingB.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,33 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 2962.500 1912.500 2475 1200 2925 1050 3450 1200 + 1 1 1.00 45.00 90.00 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1200 2850 1200 2850 1500 2100 1500 2100 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3300 1500 3300 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1500 2550 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1200 3750 1200 3750 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2175 2100 2925 2100 2925 2400 2175 2400 2175 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2925 2100 3675 2100 3675 2400 2925 2400 2925 2100 +4 1 0 50 -1 0 11 0.0000 2 210 855 2475 1425 Task$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 210 855 3375 1425 Task$_2$\001 +4 2 0 50 -1 0 11 0.0000 2 195 585 2475 1875 modify\001 +4 0 0 50 -1 0 11 0.0000 2 195 585 3375 1875 modify\001 +4 2 0 50 -1 0 11 0.0000 2 150 570 2025 2325 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 210 1005 2550 2325 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 210 1005 3300 2325 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 210 1440 3000 975 pass Object$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingC.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingC.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingC.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,30 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1200 2850 1200 2850 1500 2100 1500 2100 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3300 1500 3300 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1500 2550 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1200 3750 1200 3750 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2175 2100 2925 2100 2925 2400 2175 2400 2175 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2925 2100 3675 2100 3675 2400 2925 2400 2925 2100 +4 1 0 50 -1 0 11 0.0000 2 195 735 2475 1425 Task$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 735 3375 1425 Task$_2$\001 +4 2 0 50 -1 0 11 0.0000 2 180 510 2475 1875 modify\001 +4 0 0 50 -1 0 11 0.0000 2 135 540 3375 1875 dealloc\001 +4 2 0 50 -1 0 11 0.0000 2 135 480 2025 2325 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2550 2325 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3300 2325 Object$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingD.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingD.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/FalseSharingD.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,30 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2325 1500 2325 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2625 1500 3225 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1200 3750 1200 3750 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1200 2850 1200 2850 1500 2100 1500 2100 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2100 2850 2100 2850 2400 2100 2400 2100 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2850 2100 3600 2100 3600 2400 2850 2400 2850 2100 +4 2 0 50 -1 0 11 0.0000 2 180 510 2250 1875 modify\001 +4 0 0 50 -1 0 11 0.0000 2 135 360 3075 1875 alloc\001 +4 2 0 50 -1 0 11 0.0000 2 135 480 1950 2325 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 195 735 2475 1425 Task$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 735 3375 1425 Task$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2475 2325 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3225 2325 Object$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/FreeListAmongContainers.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/FreeListAmongContainers.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/FreeListAmongContainers.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,69 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2400 600 3000 900 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 600 3000 600 3000 900 2400 900 2400 600 +4 1 0 50 -1 0 11 0.0000 2 180 405 2700 825 Heap\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3300 1500 3600 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3900 2100 3000 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3300 2400 4200 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4500 2100 4200 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 900 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1200 3000 1200 3000 1500 2400 1500 2400 1200 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3000 1200 3600 1200 3600 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1200 4200 1200 4200 1500 3600 1500 3600 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4200 1200 4800 1200 4800 1500 4200 1500 4200 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1800 3000 1800 3000 2100 2400 2100 2400 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 2400 3000 2400 3000 2700 2400 2700 2400 2400 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3000 2400 3600 2400 3600 2700 3000 2700 3000 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1800 3600 1800 3600 2100 3000 2100 3000 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 2400 4200 2400 4200 2700 3600 2700 3600 2400 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3600 1800 4200 1800 4200 2100 3600 2100 3600 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 4200 1800 4800 1800 4800 2100 4200 2100 4200 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 4200 2400 4800 2400 4800 2700 4200 2700 4200 2400 +2 1 0 0 7 7 50 -1 -1 0.000 0 0 -1 0 0 1 + 2400 2850 +4 1 0 50 -1 0 11 0.0000 2 135 555 2700 1425 Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 3300 1425 Free\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 1425 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4500 1425 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 135 555 2700 2025 Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 555 2700 2625 Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 3300 2625 Free\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3300 2025 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 2625 Object$_4$\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 3900 2025 Free\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 4500 2025 Free\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 4500 2625 Free\001 +4 0 0 50 -1 0 11 0.0000 2 180 1110 3150 825 object free-list\001 +4 1 0 50 -1 0 11 0.0000 2 135 795 3750 1125 containers\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/FreeListWithinContainers.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/FreeListWithinContainers.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/FreeListWithinContainers.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,72 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 2850.000 1500.000 2700 1500 2850 1650 3000 1500 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 2850.000 2700.000 2700 2700 2850 2850 3000 2700 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 3150.000 1500.000 2700 2100 3150 2250 3600 2100 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 4050.000 2100.000 3900 2100 4050 2250 4200 2100 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 3750.000 2100.000 3300 2700 3750 2850 4200 2700 + 1 1 1.00 45.00 90.00 +6 2400 600 3000 900 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 600 3000 600 3000 900 2400 900 2400 600 +4 1 0 50 -1 0 11 0.0000 2 180 405 2700 825 Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1200 3000 1200 3000 1500 2400 1500 2400 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1800 3000 1800 3000 2100 2400 2100 2400 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 2400 3000 2400 3000 2700 2400 2700 2400 2400 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3000 1200 3600 1200 3600 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1800 3600 1800 3600 2100 3000 2100 3000 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3000 2400 3600 2400 3600 2700 3000 2700 3000 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 900 2400 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1500 2400 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 2100 2400 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1200 4200 1200 4200 1500 3600 1500 3600 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 2400 4200 2400 4200 2700 3600 2700 3600 2400 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3600 1800 4200 1800 4200 2100 3600 2100 3600 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4200 1200 4800 1200 4800 1500 4200 1500 4200 1200 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 4200 1800 4800 1800 4800 2100 4200 2100 4200 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 4200 2400 4800 2400 4800 2700 4200 2700 4200 2400 +4 0 0 50 -1 0 11 0.0000 2 135 1350 3150 825 container free-list\001 +4 1 0 50 -1 0 11 0.0000 2 135 555 2700 1425 Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 555 2700 2025 Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 555 2700 2625 Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 3300 1425 Free\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3300 2025 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 3225 2625 Free\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 1425 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 3900 2025 Free\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 2625 Object$_4$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4500 1425 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 4500 2025 Free\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 4500 2625 Free\001 +4 1 0 50 -1 0 11 0.0000 2 135 795 3750 1125 containers\001 +4 0 0 50 -1 0 11 0.0000 2 180 1110 3150 1650 object free-list\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/HeapStructure.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/HeapStructure.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/HeapStructure.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,103 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1650 1200 2250 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1950 1350 150 150 1950 1350 2100 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 1950 1425 T$_2$\001 +-6 +6 1200 1200 1800 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1500 1350 150 150 1500 1350 1650 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 1500 1425 T$_1$\001 +-6 +6 2100 1200 2700 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2400 1350 150 150 2400 1350 2550 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 2400 1425 T$_3$\001 +-6 +6 2700 3000 3000 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 3000 3000 3000 3000 3300 2700 3300 2700 3000 +4 1 0 50 -1 0 11 0.0000 2 135 135 2850 3225 G\001 +-6 +6 1650 2400 2250 2700 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1950 2550 150 150 1950 2550 2100 2550 +4 1 0 50 -1 0 11 0.0000 2 195 465 1950 2625 T$_2$\001 +-6 +6 1200 2400 1800 2700 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1500 2550 150 150 1500 2550 1650 2550 +4 1 0 50 -1 0 11 0.0000 2 195 465 1500 2625 T$_1$\001 +-6 +6 2100 2400 2700 2700 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2400 2550 150 150 2400 2550 2550 2550 +4 1 0 50 -1 0 11 0.0000 2 195 465 2400 2625 T$_3$\001 +-6 +6 1650 3600 2250 4500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1950 3750 150 150 1950 3750 2100 3750 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 3900 1950 4200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 4200 2100 4200 2100 4500 1800 4500 1800 4200 +4 1 0 50 -1 0 11 0.0000 2 195 495 1950 4425 H$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 1950 3825 T$_2$\001 +-6 +6 1200 3600 1800 4500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1500 3750 150 150 1500 3750 1650 3750 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1500 3900 1500 4200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 4200 1650 4200 1650 4500 1350 4500 1350 4200 +4 1 0 50 -1 0 11 0.0000 2 195 495 1500 4425 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 1500 3825 T$_1$\001 +-6 +6 2100 3600 2700 4500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2400 3750 150 150 2400 3750 2550 3750 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2400 3900 2400 4200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2250 4200 2550 4200 2550 4500 2250 4500 2250 4200 +4 1 0 50 -1 0 11 0.0000 2 195 495 2400 4425 H$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 2400 3825 T$_3$\001 +-6 +6 2850 4200 3150 4500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2850 4200 3150 4200 3150 4500 2850 4500 2850 4200 +4 1 0 50 -1 0 11 0.0000 2 135 135 3000 4425 G\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1500 1500 1950 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 1500 1950 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2400 1500 1950 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1800 2100 1800 2100 2100 1800 2100 1800 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1500 2700 1650 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1500 2700 2250 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 2700 1650 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 2700 2250 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2400 2700 2250 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1500 3000 1800 3000 1800 3300 1500 3300 1500 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 3000 2400 3000 2400 3300 2100 3300 2100 3000 +4 1 0 50 -1 0 11 0.0000 2 195 495 1950 2025 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2250 2025 $\\Leftrightarrow$\001 +4 0 0 50 -1 0 11 0.0000 2 135 240 2400 2025 OS\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 1650 3225 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2250 3225 H$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2550 3225 $\\Leftrightarrow$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 3150 3225 $\\Leftrightarrow$\001 +4 0 0 50 -1 0 11 0.0000 2 135 240 3300 3225 OS\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2700 4425 $\\Leftrightarrow$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 3300 4425 $\\Leftrightarrow$\001 +4 0 0 50 -1 0 11 0.0000 2 135 240 3450 4425 OS\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/IntExtFragmentation.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/IntExtFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/IntExtFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,74 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 3150 1200 3900 1500 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3150 1200 3900 1200 3900 1500 3150 1500 3150 1200 +4 1 0 50 -1 0 11 0.0000 2 180 600 3525 1425 Spacing\001 +-6 +6 4425 1125 5775 1575 +2 2 0 2 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4500 1200 5700 1200 5700 1500 4500 1500 4500 1200 +4 1 0 50 -1 0 11 0.0000 2 180 1020 5100 1425 Free Memory\001 +-6 +6 1200 1575 2550 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1200 1575 1200 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1500 1650 1200 1650 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2250 1650 2550 1650 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2550 1575 2550 1725 +4 1 0 50 -1 0 11 0.0000 2 135 570 1875 1725 internal\001 +-6 +6 3150 1575 4500 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3150 1575 3150 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3450 1650 3150 1650 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4200 1650 4500 1650 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 1575 4500 1725 +4 1 0 50 -1 0 11 0.0000 2 135 570 3825 1725 internal\001 +-6 +6 4500 1575 5700 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 1575 4500 1725 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4725 1650 4500 1650 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5475 1650 5700 1650 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5700 1575 5700 1725 +4 1 0 50 -1 0 11 0.0000 2 135 615 5100 1725 external\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2550 1200 2550 1500 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 1800 1200 2550 1200 2550 1500 1800 1500 1800 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3150 1200 3150 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3900 1200 3900 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1800 1200 1800 1500 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 4500 1200 4500 1500 1200 1500 1200 1200 +4 1 0 50 -1 0 11 0.0000 2 135 555 1500 1425 Header\001 +4 1 0 50 -1 0 11 0.0000 2 180 600 2175 1425 Padding\001 +4 1 0 50 -1 0 11 0.0000 2 180 510 2850 1425 Object\001 +4 1 0 50 -1 0 11 0.0000 2 135 495 4200 1425 Trailer\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/MemoryFragmentation.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/MemoryFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/MemoryFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,64 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 600 3600 600 3600 900 2100 900 2100 600 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 600 4500 600 4500 900 3600 900 3600 600 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 2100 1050 3600 1050 3600 1350 2100 1350 2100 1050 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1050 4500 1050 4500 1350 3600 1350 3600 1050 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1500 4500 1500 4500 1800 3600 1800 3600 1500 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3300 1500 3600 1500 3600 1800 3300 1800 3300 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1500 3300 1500 3300 1800 2100 1800 2100 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1950 3300 1950 3300 2250 2100 2250 2100 1950 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3300 1950 3600 1950 3600 2250 3300 2250 3300 1950 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1950 4500 1950 4500 2250 3600 2250 3600 1950 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 1800 2400 2100 2400 2100 2700 1800 2700 1800 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2400 3300 2400 3300 2700 2100 2700 2100 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3300 2400 3600 2400 3600 2700 3300 2700 3300 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 2400 4500 2400 4500 2700 3600 2700 3600 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 2400 1800 2400 1800 2700 900 2700 900 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 900 1950 2100 1950 2100 2250 900 2250 900 1950 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 1500 2100 1500 2100 1800 900 1800 900 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 1050 2100 1050 2100 1350 900 1350 900 1050 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 900 600 2100 600 2100 900 900 900 900 600 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 750 600 750 2700 +4 1 0 50 -1 0 11 0.0000 2 195 870 2850 825 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4050 825 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4050 1275 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4050 1725 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4050 2175 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4050 2625 Object$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 1725 Object$_4$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 2625 Object$_4$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 2175 Object$_4$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1500 825 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1500 1275 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1500 1725 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1350 2625 Object$_5$\001 +4 2 0 50 -1 0 11 0.0000 2 135 330 600 1725 time\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsNoOwnership.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsNoOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsNoOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,43 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1050 1800 1650 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 2100 1500 2100 1500 1800 1200 1800 1200 2100 +4 1 0 50 -1 0 11 0.0000 2 195 495 1350 2025 H$_1$\001 +-6 +6 1950 1800 2550 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2100 2400 2100 2400 1800 2100 1800 2100 2100 +4 1 0 50 -1 0 11 0.0000 2 195 495 2250 2025 H$_2$\001 +-6 +1 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 1350 1350 150 150 1350 1350 1500 1350 +1 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 2250 1350 150 150 2250 1350 2400 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1275 1800 1275 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 0 0 1.00 45.00 90.00 + 1425 1500 1425 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2 + 0 0 1.00 45.00 90.00 + 1425 1500 2175 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2 + 0 0 1.00 45.00 90.00 + 2175 1500 1425 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 0 0 1.00 45.00 90.00 + 2175 1500 2175 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 2325 1800 2325 1500 +4 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsOwnership.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsOwnership.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,39 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1050 1800 1650 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 2100 1500 2100 1500 1800 1200 1800 1200 2100 +4 1 0 50 -1 0 11 0.0000 2 195 495 1350 2025 H$_1$\001 +-6 +6 1950 1800 2550 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 2100 2400 2100 2400 1800 2100 1800 2100 2100 +4 1 0 50 -1 0 11 0.0000 2 195 495 2250 2025 H$_2$\001 +-6 +1 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 1350 1350 150 150 1350 1350 1500 1350 +1 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 2250 1350 150 150 2250 1350 2400 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 2175 1500 1425 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1425 1500 2175 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1275 1800 1275 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 2325 1800 2325 1500 +4 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsStorage.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsStorage.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsStorage.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,172 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 3000 1500 3450 1800 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 1500 3300 1500 3300 1800 3000 1800 3000 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 1750 H$_1$\001 +-6 +6 3300 1500 3750 1800 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3300 1500 3600 1500 3600 1800 3300 1800 3300 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 3325 1750 H$_2$\001 +-6 +6 4500 1500 5100 1800 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4500 1500 5100 1500 5100 1800 4500 1800 4500 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 4525 1750 H$_3$\001 +-6 +6 4050 1800 4650 2100 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4050 1800 4650 1800 4650 2100 4050 2100 4050 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 4075 2050 H$_1$\001 +-6 +6 4500 2400 5100 2700 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 4500 2400 5100 2400 5100 2700 4500 2700 4500 2400 +4 0 0 50 -1 0 9 0.0000 2 165 420 4525 2650 H$_2$\001 +-6 +6 3600 2100 4050 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3600 2100 3900 2100 3900 2400 3600 2400 3600 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 3625 2350 H$_1$\001 +-6 +6 5100 2100 5550 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 5100 2100 5400 2100 5400 2400 5100 2400 5100 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 5125 2350 H$_3$\001 +-6 +6 5700 2100 6150 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 5700 2100 6000 2100 6000 2400 5700 2400 5700 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 5725 2350 H$_3$\001 +-6 +6 5250 1800 5700 2100 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 5250 1800 5550 1800 5550 2100 5250 2100 5250 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 5275 2050 H$_3$\001 +-6 +6 3600 1500 4200 1800 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1500 4200 1500 4200 1800 3600 1800 3600 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 3625 1750 T$_1$\001 +-6 +6 4200 1500 4650 1800 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 4200 1500 4500 1500 4500 1800 4200 1800 4200 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 4225 1750 T$_2$\001 +-6 +6 5100 1500 6000 1800 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 5100 1500 6000 1500 6000 1800 5100 1800 5100 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 5125 1750 T$_3$\001 +-6 +6 3600 1800 4050 2100 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1800 4050 1800 4050 2100 3600 2100 3600 1800 +4 0 0 50 -1 0 9 0.0000 2 165 390 3625 2050 T$_4$\001 +-6 +6 4950 1800 5400 2100 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 4950 1800 5250 1800 5250 2100 4950 2100 4950 1800 +4 0 0 50 -1 0 9 0.0000 2 165 390 4975 2050 T$_5$\001 +-6 +6 4650 1800 5100 2100 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 4650 1800 4950 1800 4950 2100 4650 2100 4650 1800 +4 0 0 50 -1 0 9 0.0000 2 165 390 4675 2050 T$_6$\001 +-6 +6 5550 1800 6000 2100 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 5550 1800 6000 1800 6000 2100 5550 2100 5550 1800 +4 0 0 50 -1 0 9 0.0000 2 165 390 5575 2050 T$_4$\001 +-6 +6 3000 1800 3600 2100 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 1800 3600 1800 3600 2100 3000 2100 3000 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2050 H$_2$\001 +-6 +6 3000 2100 3450 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 2100 3300 2100 3300 2400 3000 2400 3000 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2350 H$_3$\001 +-6 +6 3300 2100 3750 2400 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3300 2100 3600 2100 3600 2400 3300 2400 3300 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 3325 2350 T$_2$\001 +-6 +6 5400 2100 5850 2400 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 5400 2100 5700 2100 5700 2400 5400 2400 5400 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 5425 2350 T$_1$\001 +-6 +6 3900 2100 4500 2400 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3900 2100 4500 2100 4500 2400 3900 2400 3900 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 3925 2350 H$_2$\001 +-6 +6 4500 2100 5100 2400 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 4500 2100 5100 2100 5100 2400 4500 2400 4500 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 4525 2350 T$_2$\001 +-6 +6 5100 2400 6000 2700 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 5100 2400 6000 2400 6000 2700 5100 2700 5100 2400 +4 0 0 50 -1 0 9 0.0000 2 165 420 5125 2650 H$_1$\001 +-6 +6 3000 2400 4500 2700 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 3000 2400 4500 2400 4500 2700 3000 2700 3000 2400 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2650 H$_3$\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2100 1200 2100 2700 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1500 2700 1800 2400 1800 2400 1500 2700 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1800 2550 1950 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1800 1650 2400 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1500 1800 1800 1500 1800 1500 1500 1800 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1950 2700 2250 2400 2250 2400 1950 2700 1950 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 2400 2700 2700 2400 2700 2400 2400 2700 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 2250 2550 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 2475 3000 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 1575 3000 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2704 1743 5100 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 2025 3000 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2709 2187 4500 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 2625 3000 2400 +4 1 0 50 -1 0 11 0.0000 2 135 885 1500 1350 Static Zone\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2550 1725 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 180 1950 4050 1350 Dynamic-Allocation Zone\001 +4 1 0 50 -1 0 11 0.0000 2 135 225 1650 1725 Hs\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2550 2625 H$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2550 2175 H$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/NonContigFragmentation.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/NonContigFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/NonContigFragmentation.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,31 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2100 1200 2100 1500 1200 1500 1200 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1200 3000 1200 3000 1500 2400 1500 2400 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1500 3300 1500 3300 1800 2700 1800 2700 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1500 1500 2100 1500 2100 1800 1500 1800 1500 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1800 3000 1800 3000 2100 1800 2100 1800 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3000 1800 3300 1800 3300 2100 3000 2100 3000 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 3000 1200 3300 1200 3300 1500 3000 1500 3000 1200 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 1200 1500 1500 1500 1500 1800 1200 1800 1200 1500 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 2100 1200 2400 1200 2400 1500 2100 1500 2100 1200 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 1200 1800 1800 1800 1800 2100 1200 2100 1200 1800 +2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 + 2100 1500 2700 1500 2700 1800 2100 1800 2100 1500 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ObjectHeaders.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ObjectHeaders.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ObjectHeaders.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,33 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1050 1125 2775 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1950 1200 1950 1500 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2700 1200 2700 1500 1200 1500 1200 1200 +4 1 0 50 -1 0 11 0.0000 2 195 915 1575 1425 Header$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2325 1425 Object$_1$\001 +-6 +6 2550 1125 4275 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3450 1200 3450 1500 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1200 4200 1200 4200 1500 2700 1500 2700 1200 +4 1 0 50 -1 0 11 0.0000 2 195 915 3075 1425 Header$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3825 1425 Object$_2$\001 +-6 +6 4050 1125 5775 1575 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4950 1200 4950 1500 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4200 1200 5700 1200 5700 1500 4200 1500 4200 1200 +4 1 0 50 -1 0 11 0.0000 2 195 915 4575 1425 Header$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 5325 1425 Object$_3$\001 +-6 Index: doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadGlobalHeap2.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadGlobalHeap2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadGlobalHeap2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,109 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2250 3975 2775 4200 +4 2 0 50 -1 0 11 0.0000 2 150 435 2625 4125 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 2650 4175 2\001 +-6 +6 2175 3075 2775 3300 +4 2 0 50 -1 0 11 0.0000 2 195 465 2625 3225 Heap\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 2650 3275 2\001 +-6 +6 1200 3000 1950 4200 +6 1350 3975 1875 4200 +4 2 0 50 -1 0 11 0.0000 2 150 435 1725 4125 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 1750 4175 1\001 +-6 +6 1275 3075 1875 3300 +4 2 0 50 -1 0 11 0.0000 2 195 465 1725 3225 Heap\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 1750 3275 1\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1425 3300 1425 3900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1725 3900 1725 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 3000 1950 3000 1950 3300 1200 3300 1200 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 3900 1950 3900 1950 4200 1200 4200 1200 3900 +4 1 0 50 -1 0 11 1.5708 2 150 405 1350 3600 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 150 615 1800 3600 dealloc\001 +-6 +6 3075 3075 3675 3300 +4 2 0 50 -1 0 11 0.0000 2 195 465 3525 3225 Heap\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 3550 3275 3\001 +-6 +6 3150 3975 3675 4200 +4 2 0 50 -1 0 11 0.0000 2 150 435 3525 4125 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 3550 4175 3\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1875 2400 1425 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1725 3000 2175 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2325 2400 2325 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2625 3000 2625 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3075 2400 3525 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3225 3000 2775 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1725 1200 3225 1200 3225 1500 1725 1500 1725 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1725 2100 3225 2100 3225 2400 1725 2400 1725 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2325 1500 2325 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2625 2100 2625 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2325 3300 2325 3900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2625 3900 2625 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 3000 2850 3000 2850 3300 2100 3300 2100 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 3900 2850 3900 2850 4200 2100 4200 2100 3900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3225 3300 3225 3900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3525 3900 3525 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 3900 3750 3900 3750 4200 3000 4200 3000 3900 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 3000 3750 3000 3750 3300 3000 3300 3000 3000 +4 1 0 50 -1 0 11 0.0000 2 195 1545 2475 1425 Operating System\001 +4 1 0 50 -1 0 11 0.0000 2 195 1035 2475 2325 Gobal Heap\001 +4 1 0 50 -1 0 11 1.5708 2 150 405 2250 1800 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 150 615 2700 1800 dealloc\001 +4 1 0 50 -1 0 11 0.8727 2 150 405 1575 2700 alloc\001 +4 1 0 50 -1 0 11 0.8727 2 150 615 1875 2700 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 150 405 2250 2700 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 150 615 2700 2700 dealloc\001 +4 1 0 50 -1 0 11 5.4105 2 150 615 3450 2775 dealloc\001 +4 1 0 50 -1 0 11 5.4105 2 150 405 3150 2775 alloc\001 +4 1 0 50 -1 0 11 1.5708 2 150 405 2250 3600 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 150 615 2700 3600 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 150 405 3150 3600 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 150 615 3600 3600 dealloc\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadHeap.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadHeap.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadHeap.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,44 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2700 1800 3000 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1800 3000 1800 3000 2100 2700 2100 2700 1800 +4 1 0 50 -1 0 11 0.0000 2 135 135 2850 2025 G\001 +-6 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 1350 150 150 1350 1350 1500 1350 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1800 1350 150 150 1800 1350 1950 1350 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2250 1350 150 150 2250 1350 2400 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1350 1500 1350 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1800 1500 1800 1500 2100 1200 2100 1200 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1650 1800 1950 1800 1950 2100 1650 2100 1650 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2100 1800 2400 1800 2400 2100 2100 2100 2100 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1800 1500 1800 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 2250 1500 2250 1800 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2550 2025 $\\Leftrightarrow$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 3150 2025 $\\Leftrightarrow$\001 +4 0 0 50 -1 0 11 0.0000 2 135 240 3300 2025 OS\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 1350 2025 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 1800 2025 H$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 1800 1425 T$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2250 2025 H$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_3$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/PrivatePublicHeaps2.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/PrivatePublicHeaps2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/PrivatePublicHeaps2.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,100 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1200 1200 2400 1500 +6 1200 1275 2400 1500 +4 2 0 50 -1 0 11 0.0000 2 180 915 2250 1425 Public Heap\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 2275 1475 1\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2400 1200 2400 1500 1200 1500 1200 1200 +-6 +6 3900 1200 5100 1500 +6 3900 1275 5100 1500 +4 0 0 50 -1 0 9 0.0000 2 105 75 4975 1475 2\001 +4 2 0 50 -1 0 11 0.0000 2 180 915 4950 1425 Public Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 1200 5100 1200 5100 1500 3900 1500 3900 1200 +-6 +6 1425 2100 2700 2400 +6 1425 2175 2550 2400 +4 2 0 50 -1 0 11 0.0000 2 180 990 2550 2325 Private Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1500 2100 2700 2100 2700 2400 1500 2400 1500 2100 +4 0 0 50 -1 0 9 0.0000 2 105 75 2575 2375 1\001 +-6 +6 3525 2100 4800 2400 +6 3525 2175 4650 2400 +4 2 0 50 -1 0 11 0.0000 2 180 990 4650 2325 Private Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 2100 4800 2100 4800 2400 3600 2400 3600 2100 +4 0 0 50 -1 0 9 0.0000 2 105 75 4675 2375 2\001 +-6 +6 1200 3000 2400 3300 +6 1575 3075 2100 3300 +4 2 0 50 -1 0 11 0.0000 2 135 375 1950 3225 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 1975 3275 1\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 3000 2400 3000 2400 3300 1200 3300 1200 3000 +-6 +6 3900 3000 5100 3300 +6 4275 3075 4800 3300 +4 2 0 50 -1 0 11 0.0000 2 135 375 4650 3225 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 4675 3275 2\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 3000 5100 3000 5100 3300 3900 3300 3900 3000 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1275 1500 1275 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1950 3000 1950 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1575 2400 1575 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5025 1500 5025 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4350 2400 4350 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4350 2100 4350 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4650 3000 4650 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3900 3000 2400 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2400 3000 3900 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1950 2100 1950 1500 +4 1 0 50 -1 0 11 0.0000 2 180 540 3150 1425 locking\001 +4 1 0 50 -1 0 11 1.5708 2 135 540 1875 1800 dealloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 540 4425 1800 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 540 1875 2700 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 360 1500 2700 alloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 360 1200 2250 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 540 4725 2700 dealloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 360 4425 2700 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 360 5100 2250 alloc\001 +4 1 0 50 -1 0 11 5.4803 2 135 540 3375 2775 dealloc\001 +4 1 0 50 -1 0 11 0.8029 2 180 780 2700 2625 ownership\001 +4 1 0 50 -1 0 11 0.8029 2 135 540 2925 2775 dealloc\001 +4 1 0 50 -1 0 11 5.4803 2 180 780 3600 2625 ownership\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/ProgramFalseSharing.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/ProgramFalseSharing.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/ProgramFalseSharing.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,56 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 4050.000 4662.500 2850 1575 4050 1350 5250 1575 + 1 1 1.00 45.00 90.00 +6 2550 3000 4350 3300 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2550 3000 3450 3000 3450 3300 2550 3300 2550 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3450 3000 4350 3000 4350 3300 3450 3300 3450 3000 +4 1 0 50 -1 0 11 0.0000 2 195 870 3000 3225 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 3900 3225 Object$_2$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 2100 2250 2100 2250 2400 1350 2400 1350 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2250 2100 3150 2100 3150 2400 2250 2400 2250 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1500 3300 1500 3300 2550 1200 2550 1200 1500 +2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3750 2100 4650 2100 4650 2400 3750 2400 3750 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4650 2100 5550 2100 5550 2400 4650 2400 4650 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1500 5700 1500 5700 2550 3600 2550 3600 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2250 2550 3000 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4650 2550 3900 3000 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 3150 1800 3150 1575 2550 1575 2550 1800 3150 1800 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 5550 1800 5550 1575 4950 1575 4950 1800 5550 1800 +4 1 0 50 -1 0 11 0.0000 2 195 735 2850 1725 Task$_1$\001 +4 0 0 50 -1 0 11 0.0000 2 195 720 1275 1725 CPU$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 135 480 2250 2025 Cache\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 1800 2325 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 2700 2325 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 735 5250 1725 Task$_2$\001 +4 0 0 50 -1 0 11 0.0000 2 195 720 3675 1725 CPU$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 4200 2325 Object$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 870 5100 2325 Object$_2$\001 +4 1 0 50 -1 0 11 0.0000 2 135 480 4650 2025 Cache\001 +4 2 0 50 -1 0 11 0.0000 2 180 630 2475 3225 Memory\001 +4 2 0 50 -1 2 11 0.0000 2 135 585 2550 2850 1. alloc\001 +4 0 0 50 -1 2 11 0.0000 2 180 720 2700 2775 3. modify\001 +4 0 0 50 -1 2 11 0.0000 2 180 720 4350 2850 4. modify\001 +4 1 0 50 -1 2 11 0.0000 2 195 2400 4050 1275 2. pass Object$_2$ reference\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/RemoteFreeList.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/RemoteFreeList.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/RemoteFreeList.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,88 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1125 1200 2400 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2400 1200 2400 1500 1200 1500 1200 1200 +4 2 0 50 -1 0 11 0.0000 2 180 990 2250 1425 Private Heap\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 2275 1475 1\001 +-6 +6 3825 1200 5100 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 1200 5100 1200 5100 1500 3900 1500 3900 1200 +4 0 0 50 -1 0 9 0.0000 2 105 75 4975 1475 2\001 +4 2 0 50 -1 0 11 0.0000 2 180 990 4950 1425 Private Heap\001 +-6 +6 1725 2100 3000 2400 +6 1725 2175 2850 2325 +4 2 0 50 -1 0 11 0.0000 2 135 975 2850 2325 Remote Free\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 2100 3000 2100 3000 2400 1800 2400 1800 2100 +4 0 0 50 -1 0 9 0.0000 2 105 75 2875 2375 1\001 +-6 +6 3225 2100 4500 2400 +6 3225 2175 4350 2325 +4 2 0 50 -1 0 11 0.0000 2 135 975 4350 2325 Remote Free\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3300 2100 4500 2100 4500 2400 3300 2400 3300 2100 +4 0 0 50 -1 0 9 0.0000 2 105 75 4375 2375 2\001 +-6 +6 1200 3000 2400 3300 +6 1575 3075 2100 3300 +4 2 0 50 -1 0 11 0.0000 2 135 375 1950 3225 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 1975 3275 1\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 3000 2400 3000 2400 3300 1200 3300 1200 3000 +-6 +6 3900 3000 5100 3300 +6 4275 3075 4800 3300 +4 2 0 50 -1 0 11 0.0000 2 135 375 4650 3225 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 4675 3275 2\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 3000 5100 3000 5100 3300 3900 3300 3900 3000 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3900 3000 3000 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1275 1500 1275 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1575 3000 1575 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4725 3000 4725 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5025 1500 5025 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2400 3000 3300 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2100 2100 2100 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4200 2100 4200 1500 +4 1 0 50 -1 0 11 1.5708 2 135 540 1500 2250 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 360 1200 2250 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 540 4800 2250 dealloc\001 +4 1 0 50 -1 0 11 0.0000 2 180 540 3150 2025 locking\001 +4 1 0 50 -1 0 11 0.5934 2 135 540 2850 2925 dealloc\001 +4 1 0 50 -1 0 11 5.6898 2 135 540 3450 2925 dealloc\001 +4 1 0 50 -1 0 11 0.5934 2 180 780 2700 2725 ownership\001 +4 1 0 50 -1 0 11 5.6898 2 180 780 3600 2725 ownership\001 +4 1 0 50 -1 0 11 1.5708 2 135 360 2025 1800 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 360 5100 2250 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 360 4275 1800 alloc\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/SharedHeaps.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/SharedHeaps.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/SharedHeaps.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,59 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1500 1200 2100 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1800 1350 150 150 1800 1350 1950 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 1800 1425 T$_2$\001 +-6 +6 1050 1200 1650 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 1350 150 150 1350 1350 1500 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001 +-6 +6 1950 1200 2550 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2250 1350 150 150 2250 1350 2400 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_3$\001 +-6 +6 1275 1800 1875 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1425 1800 1725 1800 1725 2100 1425 2100 1425 1800 +4 1 0 50 -1 0 11 0.0000 2 195 495 1575 2025 H$_1$\001 +-6 +6 1725 1800 2325 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1875 1800 2175 1800 2175 2100 1875 2100 1875 1800 +4 1 0 50 -1 0 11 0.0000 2 195 495 2025 2025 H$_2$\001 +-6 +6 2475 1800 2775 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2475 1800 2775 1800 2775 2100 2475 2100 2475 1800 +4 1 0 50 -1 0 11 0.0000 2 135 135 2625 2025 G\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1275 1500 1500 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1425 1500 1950 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1725 1500 1650 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1875 1500 2025 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 2250 1500 2100 1800 +4 0 0 50 -1 0 11 0.0000 2 135 240 3075 2025 OS\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2325 2025 $\\Leftrightarrow$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2925 2025 $\\Leftrightarrow$\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/SingleHeap.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/SingleHeap.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/SingleHeap.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,38 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1500 1200 2100 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1800 1350 150 150 1800 1350 1950 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 1800 1425 T$_2$\001 +-6 +6 1050 1200 1650 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 1350 150 150 1350 1350 1500 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001 +-6 +6 1950 1200 2550 1500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2250 1350 150 150 2250 1350 2400 1350 +4 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_3$\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1350 1500 1725 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 2250 1500 1875 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1650 1800 1950 1800 1950 2100 1650 2100 1650 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 0 0 1.00 45.00 90.00 + 0 0 1.00 45.00 90.00 + 1800 1500 1800 1800 +4 1 0 50 -1 0 11 0.0000 2 195 495 1800 2025 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 195 1320 2100 2025 $\\Leftrightarrow$\001 +4 0 0 50 -1 0 11 0.0000 2 135 240 2250 2025 OS\001 Index: doc/theses/mubeen_zulfiqar_MMath/figures/SuperContainers.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/figures/SuperContainers.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/figures/SuperContainers.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,66 @@ +#FIG 3.2 Produced by xfig version 3.2.5-alpha5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 2100.000 1425.000 1800 1200 2100 1050 2400 1200 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 2656.250 3062.500 2100 1050 2700 975 3600 1200 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 3300.000 7487.500 2700 975 3900 975 5100 1200 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 3825.000 13587.500 2700 975 4950 975 6450 1200 + 1 1 1.00 45.00 90.00 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 1 0 2100.000 2025.000 1800 1800 2100 1650 2400 1800 + 1 1 1.00 45.00 90.00 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2400 1200 2400 1500 1200 1500 1200 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1200 2700 1200 2700 1500 2400 1500 2400 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1200 3600 1200 3600 1500 2700 1500 2700 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1200 3900 1200 3900 1500 3600 1500 3600 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 1200 5100 1200 5100 1500 3900 1500 3900 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5100 1200 5400 1200 5400 1500 5100 1500 5100 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5400 1200 6450 1200 6450 1500 5400 1500 5400 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1800 2400 1800 2400 2100 1200 2100 1200 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2400 1800 2700 1800 2700 2100 2400 2100 2400 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1200 2175 1200 2325 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4125 2250 1200 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4725 2250 7200 2250 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1800 6450 1800 6450 2100 2700 2100 2700 1800 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 6450 1200 7200 1200 7200 1500 6450 1500 6450 1200 +2 2 0 1 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 6450 1800 7200 1800 7200 2100 6450 2100 6450 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 7200 2175 7200 2325 +4 1 0 50 -1 0 11 0.0000 2 180 1035 1800 1425 Super Header\001 +4 1 0 50 -1 0 11 0.0000 2 180 810 3150 1425 8B objects\001 +4 1 0 50 -1 0 11 0.0000 2 135 135 3750 1425 H\001 +4 1 0 50 -1 0 11 0.0000 2 180 990 4500 1425 256B objects\001 +4 1 0 50 -1 0 11 0.0000 2 135 135 2550 1425 H\001 +4 1 0 50 -1 0 11 0.0000 2 135 135 5250 1425 H\001 +4 1 0 50 -1 0 11 0.0000 2 180 900 5925 1425 64B objects\001 +4 1 0 50 -1 0 11 0.0000 2 180 1035 1800 2025 Super Header\001 +4 1 0 50 -1 0 11 0.0000 2 135 135 2550 2025 H\001 +4 1 0 50 -1 0 11 0.0000 2 135 435 4425 2325 64KB\001 +4 1 0 50 -1 0 11 0.0000 2 180 945 4650 2025 4KB objects\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 6825 1425 Free\001 +4 1 0 50 -1 0 11 0.0000 2 135 345 6825 2025 Free\001 Index: doc/theses/mubeen_zulfiqar_MMath/intro.tex =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/intro.tex (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ doc/theses/mubeen_zulfiqar_MMath/intro.tex (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -1,4 +1,154 @@ \chapter{Introduction} + +\section{Introduction} + +% Shared-memory multi-processor computers are ubiquitous and important for improving application performance. +% However, writing programs that take advantage of multiple processors is not an easy task~\cite{Alexandrescu01b}, \eg shared resources can become a bottleneck when increasing (scaling) threads. +% One crucial shared resource is program memory, since it is used by all threads in a shared-memory concurrent-program~\cite{Berger00}. +% Therefore, providing high-performance, scalable memory-management is important for virtually all shared-memory multi-threaded programs. + +Memory management takes a sequence of program generated allocation/deallocation requests and attempts to satisfy them within a fixed-sized block of memory while minimizing the total amount of memory used. +A general-purpose dynamic-allocation algorithm cannot anticipate future allocation requests so its output is rarely optimal. +However, memory allocators do take advantage of regularities in allocation patterns for typical programs to produce excellent results, both in time and space (similar to LRU paging). +In general, allocators use a number of similar techniques, each optimizing specific allocation patterns. +Nevertheless, memory allocators are a series of compromises, occasionally with some static or dynamic tuning parameters to optimize specific program-request patterns. + + +\subsection{Memory Structure} +\label{s:MemoryStructure} + +\VRef[Figure]{f:ProgramAddressSpace} shows the typical layout of a program's address space divided into the following zones (right to left): static code/data, dynamic allocation, dynamic code/data, and stack, with free memory surrounding the dynamic code/data~\cite{memlayout}. +Static code and data are placed into memory at load time from the executable and are fixed-sized at runtime. +Dynamic-allocation memory starts empty and grows/shrinks as the program dynamically creates/deletes variables with independent lifetime. +The programming-language's runtime manages this area, where management complexity is a function of the mechanism for deleting variables. +Dynamic code/data memory is managed by the dynamic loader for libraries loaded at runtime, which is complex especially in a multi-threaded program~\cite{Huang06}. +However, changes to the dynamic code/data space are typically infrequent, many occurring at program startup, and are largely outside of a program's control. +Stack memory is managed by the program call-mechanism using simple LIFO management, which works well for sequential programs. +For multi-threaded programs (and coroutines), a new stack is created for each thread; +these thread stacks are commonly created in dynamic-allocation memory. +This thesis focuses on management of the dynamic-allocation memory. + +\begin{figure} +\centering +\input{AddressSpace} +\vspace{-5pt} +\caption{Program Address Space Divided into Zones} +\label{f:ProgramAddressSpace} +\end{figure} + + +\subsection{Dynamic Memory-Management} +\label{s:DynamicMemoryManagement} + +Modern programming languages manage dynamic-allocation memory in different ways. +Some languages, such as Lisp~\cite{CommonLisp}, Java~\cite{Java}, Go~\cite{Go}, Haskell~\cite{Haskell}, provide explicit allocation but \emph{implicit} deallocation of data through garbage collection~\cite{Wilson92}. +In general, garbage collection supports memory compaction, where dynamic (live) data is moved during runtime to better utilize space. +However, moving data requires finding pointers to it and updating them to reflect new data locations. +Programming languages such as C~\cite{C}, \CC~\cite{C++}, and Rust~\cite{Rust} provide the programmer with explicit allocation \emph{and} deallocation of data. +These languages cannot find and subsequently move live data because pointers can be created to any storage zone, including internal components of allocated objects, and may contain temporary invalid values generated by pointer arithmetic. +Attempts have been made to perform quasi garbage collection in C/\CC~\cite{Boehm88}, but it is a compromise. +This thesis only examines dynamic memory-management with \emph{explicit} deallocation. +While garbage collection and compaction are not part this work, many of the results are applicable to the allocation phase in any memory-management approach. + +Most programs use a general-purpose allocator, often the one provided implicitly by the programming-language's runtime. +When this allocator proves inadequate, programmers often write specialize allocators for specific needs. +C and \CC allow easy replacement of the default memory allocator with an alternative specialized or general-purpose memory-allocator. +(Jikes RVM MMTk~\cite{MMTk} provides a similar generalization for the Java virtual machine.) +However, high-performance memory-allocators for kernel and user multi-threaded programs are still being designed and improved. +For this reason, several alternative general-purpose allocators have been written for C/\CC with the goal of scaling in a multi-threaded program~\cite{Berger00,mtmalloc,streamflow,tcmalloc}. +This work examines the design of high-performance allocators for use by kernel and user multi-threaded applications written in C/\CC. + + +\subsection{Contributions} +\label{s:Contributions} + +This work provides the following contributions in the area of concurrent dynamic allocation: +\begin{enumerate} +\item +Implementation of a new stand-lone concurrent memory allocator ($\approx$1,200 lines of code) for C/\CC programs using kernel threads (1:1 threading), and specialized versions of the allocator for programming languages \uC and \CFA using user-level threads running over multiple kernel threads (M:N threading). + +\item +Adopt the return of @nullptr@ for a zero-sized allocation, rather than an actual memory address, both of which can be passed to @free@. +Most allocators use @nullptr@ to indicate an allocation failure, such as full memory; +hence the need to return an alternate value for a zero-sized allocation. +The alternative is to abort the program on allocation failure. +In theory, notifying the programmer of a failure allows recovery; +in practice, it is almost impossible to gracefully recover from allocation failure, especially full memory, so adopting the cheaper return @nullptr@ for a zero-sized allocation is chosen. + +\item +Extended the standard C heap functionality by preserving with each allocation its original request size versus the amount allocated due to bucketing, if an allocation is zero fill, and the allocation alignment. + +\item +Use the zero fill and alignment as \emph{sticky} properties for @realloc@, to realign existing storage, or preserve existing zero-fill and alignment when storage is copied. +Without this extension, it is unsafe to @realloc@ storage initially allocated with zero-fill/alignment as these properties are not preserved when copying. +This silent generation of a problem is unintuitive to programmers and difficult to locate because it is transient. + +\item +Provide additional heap operations to complete programmer expectation with respect to accessing different allocation properties. +\begin{itemize} +\item +@resize( oaddr, size )@ re-purpose an old allocation for a new type \emph{without} preserving fill or alignment. +\item +@resize( oaddr, alignment, size )@ re-purpose an old allocation with new alignment but \emph{without} preserving fill. +\item +@realloc( oaddr, alignment, size )@ same as previous @realloc@ but adding or changing alignment. +\item +@aalloc( dim, elemSize )@ same as @calloc@ except memory is \emph{not} zero filled. +\item +@amemalign( alignment, dim, elemSize )@ same as @aalloc@ with memory alignment. +\item +@cmemalign( alignment, dim, elemSize )@ same as @calloc@ with memory alignment. +\end{itemize} + +\item +Provide additional query operations to access information about an allocation: +\begin{itemize} +\item +@malloc_alignment( addr )@ returns the alignment of the allocation pointed-to by @addr@. +If the allocation is not aligned or @addr@ is the @nulladdr@, the minimal alignment is returned. +\item +@malloc_zero_fill( addr )@ returns a boolean result indicating if the memory pointed-to by @addr@ is allocated with zero fill, e.g., by @calloc@/@cmemalign@. +\item +@malloc_size( addr )@ returns the size of the memory allocation pointed-to by @addr@. +\item +@malloc_usable_size( addr )@ returns the usable size of the memory pointed-to by @addr@, i.e., the bin size containing the allocation, where @malloc_size( addr )@ $\le$ @malloc_usable_size( addr )@. +\end{itemize} + +\item +Provide complete and fast allocation statistics to help understand program behaviour: +\begin{itemize} +\item +@malloc_stats()@ print memory-allocation statistics on the file-descriptor set by @malloc_stats_fd@. +\item +@malloc_info( options, stream )@ print memory-allocation statistics as an XML string on the specified file-descriptor set by @malloc_stats_fd@. +\item +@malloc_stats_fd( fd )@ set file-descriptor number for printing memory-allocation statistics (default @STDERR_FILENO@). +This file descriptor is used implicitly by @malloc_stats@ and @malloc_info@. +\end{itemize} + +\item +Provide mostly contention-free allocation and free operations via a heap-per-kernel-thread implementation. + +\item +Provide extensive contention-free runtime checks to valid allocation operations and identify the amount of unfreed storage at program termination. + +\item +Build 4 different versions of the allocator: +\begin{itemize} +\item +static or dynamic linking +\item +statistic/debugging (testing) or no statistic/debugging (performance) +\end{itemize} +A program may link to any of these 4 versions of the allocator often without recompilation. +(It is possible to separate statistics and debugging, giving 8 different versions.) + +\item +A micro-benchmark test-suite for comparing allocators rather than relying on a suite of arbitrary programs. +These micro-benchmarks have adjustment knobs to simulate allocation patterns hard-coded into arbitrary test programs +\end{enumerate} + +\begin{comment} \noindent ==================== @@ -26,9 +176,9 @@ \section{Introduction} -Dynamic memory allocation and management is one of the core features of C. It gives programmer the freedom to allocate, free, use, and manage dynamic memory himself. The programmer is not given the complete control of the dynamic memory management instead an interface of memory allocator is given to the progrmmer that can be used to allocate/free dynamic memory for the application's use. - -Memory allocator is a layer between thr programmer and the system. Allocator gets dynamic memory from the system in heap/mmap area of application storage and manages it for programmer's use. - -GNU C Library (FIX ME: cite this) provides an interchangeable memory allocator that can be replaced with a custom memory allocator that supports required features and fulfills application's custom needs. It also allows others to innovate in memory allocation and design their own memory allocator. GNU C Library has set guidelines that should be followed when designing a standalone memory allocator. GNU C Library requires new memory allocators to have atlease following set of functions in their allocator's interface: +Dynamic memory allocation and management is one of the core features of C. It gives programmer the freedom to allocate, free, use, and manage dynamic memory himself. The programmer is not given the complete control of the dynamic memory management instead an interface of memory allocator is given to the programmer that can be used to allocate/free dynamic memory for the application's use. + +Memory allocator is a layer between the programmer and the system. Allocator gets dynamic memory from the system in heap/mmap area of application storage and manages it for programmer's use. + +GNU C Library (FIX ME: cite this) provides an interchangeable memory allocator that can be replaced with a custom memory allocator that supports required features and fulfills application's custom needs. It also allows others to innovate in memory allocation and design their own memory allocator. GNU C Library has set guidelines that should be followed when designing a stand-alone memory allocator. GNU C Library requires new memory allocators to have at lease following set of functions in their allocator's interface: \begin{itemize} @@ -43,5 +193,5 @@ \end{itemize} -In addition to the above functions, GNU C Library also provides some more functions to increase the usability of the dynamic memory allocator. Most standalone allocators also provide all or some of the above additional functions. +In addition to the above functions, GNU C Library also provides some more functions to increase the usability of the dynamic memory allocator. Most stand-alone allocators also provide all or some of the above additional functions. \begin{itemize} @@ -60,5 +210,5 @@ \end{itemize} -With the rise of concurrent applications, memory allocators should be able to fulfill dynamic memory requests from multiple threads in parallel without causing contention on shared resources. There needs to be a set of a standard benchmarks that can be used to evaluate an allocator's performance in different scenerios. +With the rise of concurrent applications, memory allocators should be able to fulfill dynamic memory requests from multiple threads in parallel without causing contention on shared resources. There needs to be a set of a standard benchmarks that can be used to evaluate an allocator's performance in different scenarios. \section{Research Objectives} @@ -69,7 +219,8 @@ Design a lightweight concurrent memory allocator with added features and usability that are currently not present in the other memory allocators. \item -Design a suite of benchmarks to evalute multiple aspects of a memory allocator. +Design a suite of benchmarks to evaluate multiple aspects of a memory allocator. \end{itemize} \section{An outline of the thesis} LAST FIX ME: add outline at the end +\end{comment} Index: doc/theses/mubeen_zulfiqar_MMath/pictures/MultipleHeapsOwnershipStorage.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/pictures/MultipleHeapsOwnershipStorage.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/pictures/MultipleHeapsOwnershipStorage.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,240 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 4500 2400 6000 2700 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 4500 2400 6000 2400 6000 2700 4500 2700 4500 2400 +4 0 0 50 -1 0 9 0.0000 2 165 420 4525 2650 H$_1$\001 +-6 +6 3000 2400 4500 2700 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 3000 2400 4500 2400 4500 2700 3000 2700 3000 2400 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2650 H$_2$\001 +-6 +6 3000 2700 4500 3000 +2 2 0 1 0 7 60 -1 13 0.000 0 0 -1 0 0 5 + 3000 2700 4500 2700 4500 3000 3000 3000 3000 2700 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2950 H$_3$\001 +-6 +6 3000 1500 4650 1800 +6 3000 1500 3450 1800 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 1500 3300 1500 3300 1800 3000 1800 3000 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 1750 H$_1$\001 +-6 +6 4200 1500 4650 1800 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4200 1500 4500 1500 4500 1800 4200 1800 4200 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 4225 1750 H$_1$\001 +-6 +6 3900 1500 4350 1800 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3900 1500 4200 1500 4200 1800 3900 1800 3900 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 3925 1750 H$_1$\001 +-6 +6 3300 1500 3750 1800 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3300 1500 3600 1500 3600 1800 3300 1800 3300 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 3325 1750 T$_1$\001 +-6 +6 3600 1500 4050 1800 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1500 3900 1500 3900 1800 3600 1800 3600 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 3625 1750 T$_2$\001 +-6 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3300 1500 3300 1800 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 4200 1500 4200 1800 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3900 1500 3900 1800 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3600 1500 3600 1800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1500 4500 1500 4500 1800 3000 1800 3000 1500 +-6 +6 4500 1500 6000 1800 +6 4500 1500 5100 1800 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4500 1500 5100 1500 5100 1800 4500 1800 4500 1500 +4 0 0 50 -1 0 9 0.0000 2 165 420 4525 1750 H$_3$\001 +-6 +6 5100 1500 5550 1800 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 5100 1500 5550 1500 5550 1800 5100 1800 5100 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 5125 1750 T$_3$\001 +-6 +6 5550 1500 6000 1800 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 5550 1500 6000 1500 6000 1800 5550 1800 5550 1500 +4 0 0 50 -1 0 9 0.0000 2 165 390 5575 1750 T$_1$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 1500 6000 1500 6000 1800 4500 1800 4500 1500 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 5100 1500 5100 1800 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 5550 1500 5550 1800 +-6 +6 3000 1800 4650 2100 +6 4200 1800 4650 2100 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4200 1800 4500 1800 4500 2100 4200 2100 4200 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 4225 2050 H$_2$\001 +-6 +6 3900 1800 4350 2100 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3900 1800 4200 1800 4200 2100 3900 2100 3900 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 3925 2050 H$_2$\001 +-6 +6 3000 1800 3600 2100 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 1800 3600 1800 3600 2100 3000 2100 3000 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2050 H$_2$\001 +-6 +6 3600 1800 4050 2100 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3600 1800 3900 1800 3900 2100 3600 2100 3600 1800 +4 0 0 50 -1 0 9 0.0000 2 165 390 3625 2050 T$_3$\001 +-6 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3600 1800 3600 2100 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3900 1800 3900 2100 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 4200 1800 4200 2100 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1800 4500 1800 4500 2100 3000 2100 3000 1800 +-6 +6 4500 1800 6000 2100 +6 4500 1800 4950 2100 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4500 1800 4800 1800 4800 2100 4500 2100 4500 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 4525 2050 H$_1$\001 +-6 +6 5400 1800 6000 2100 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 5400 1800 6000 1800 6000 2100 5400 2100 5400 1800 +4 0 0 50 -1 0 9 0.0000 2 165 420 5425 2050 H$_1$\001 +-6 +6 4800 1800 5400 2100 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 4800 1800 5400 1800 5400 2100 4800 2100 4800 1800 +4 0 0 50 -1 0 9 0.0000 2 165 390 4825 2050 T$_1$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 1800 6000 1800 6000 2100 4500 2100 4500 1800 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 4800 1800 4800 2100 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 5400 1800 5400 2100 +-6 +6 3000 2100 4650 2400 +6 4200 2100 4650 2400 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4200 2100 4500 2100 4500 2400 4200 2400 4200 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 4225 2350 H$_3$\001 +-6 +6 3000 2100 3450 2400 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3000 2100 3300 2100 3300 2400 3000 2400 3000 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 3025 2350 H$_3$\001 +-6 +6 3600 2100 4050 2400 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 3600 2100 3900 2100 3900 2400 3600 2400 3600 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 3625 2350 H$_3$\001 +-6 +6 3300 2100 3750 2400 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3300 2100 3600 2100 3600 2400 3300 2400 3300 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 3325 2350 T$_1$\001 +-6 +6 3900 2100 4350 2400 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 3900 2100 4200 2100 4200 2400 3900 2400 3900 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 3925 2350 T$_1$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 2100 4500 2100 4500 2400 3000 2400 3000 2100 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3300 2100 3300 2400 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3900 2100 3900 2400 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 4200 2100 4200 2400 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3600 2100 3600 2400 +-6 +6 4500 2100 6000 2400 +6 4950 2100 5550 2400 +2 2 0 0 0 7 60 -1 17 0.000 0 0 -1 0 0 5 + 4950 2100 5550 2100 5550 2400 4950 2400 4950 2100 +4 0 0 50 -1 0 9 0.0000 2 165 420 4975 2350 H$_2$\001 +-6 +6 4500 2100 4950 2400 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 4500 2100 4950 2100 4950 2400 4500 2400 4500 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 4525 2350 T$_2$\001 +-6 +6 5550 2100 6000 2400 +2 2 0 0 0 7 60 -1 -1 0.000 0 0 -1 0 0 5 + 5550 2100 6000 2100 6000 2400 5550 2400 5550 2100 +4 0 0 50 -1 0 9 0.0000 2 165 390 5575 2350 T$_3$\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4500 2100 6000 2100 6000 2400 4500 2400 4500 2100 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 4950 2100 4950 2400 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 5550 2100 5550 2400 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2100 1200 2100 3000 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1500 2700 1800 2400 1800 2400 1500 2700 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1800 2550 1950 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1800 1650 2400 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1800 1500 1800 1800 1500 1800 1500 1500 1800 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 1950 2700 2250 2400 2250 2400 1950 2700 1950 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2700 2400 2700 2700 2400 2700 2400 2400 2700 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 2250 2550 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 2475 3000 2100 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 1575 3000 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2700 2025 3000 1800 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2704 1743 4500 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2691 2163 3000 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2691 2618 3000 2700 +4 1 0 50 -1 0 11 0.0000 2 135 885 1500 1350 Static Zone\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2550 1725 H$_1$\001 +4 1 0 50 -1 0 11 0.0000 2 180 1950 4050 1350 Dynamic-Allocation Zone\001 +4 1 0 50 -1 0 11 0.0000 2 135 225 1650 1725 Hs\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2550 2625 H$_3$\001 +4 1 0 50 -1 0 11 0.0000 2 195 495 2550 2175 H$_2$\001 Index: doc/theses/mubeen_zulfiqar_MMath/pictures/PrivatePublicHeaps.fig =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/pictures/PrivatePublicHeaps.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) +++ doc/theses/mubeen_zulfiqar_MMath/pictures/PrivatePublicHeaps.fig (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -0,0 +1,117 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1200 1200 2400 1500 +6 1200 1275 2400 1500 +4 2 0 50 -1 0 11 0.0000 2 180 915 2250 1425 Public Heap\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 2275 1475 1\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 2400 1200 2400 1500 1200 1500 1200 1200 +-6 +6 3900 1200 5100 1500 +6 3900 1275 5100 1500 +4 0 0 50 -1 0 9 0.0000 2 105 75 4975 1475 2\001 +4 2 0 50 -1 0 11 0.0000 2 180 915 4950 1425 Public Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3900 1200 5100 1200 5100 1500 3900 1500 3900 1200 +-6 +6 1425 2100 2700 2400 +6 1425 2175 2550 2400 +4 2 0 50 -1 0 11 0.0000 2 180 990 2550 2325 Private Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1500 2100 2700 2100 2700 2400 1500 2400 1500 2100 +4 0 0 50 -1 0 9 0.0000 2 105 75 2575 2375 1\001 +-6 +6 3525 2100 4800 2400 +6 3525 2175 4650 2400 +4 2 0 50 -1 0 11 0.0000 2 180 990 4650 2325 Private Heap\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 2100 4800 2100 4800 2400 3600 2400 3600 2100 +4 0 0 50 -1 0 9 0.0000 2 105 75 4675 2375 2\001 +-6 +6 2550 600 3750 900 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2550 600 3750 600 3750 900 2550 900 2550 600 +4 1 0 50 -1 0 11 0.0000 2 180 945 3150 825 Global Heap\001 +-6 +6 1575 3075 2100 3300 +4 2 0 50 -1 0 11 0.0000 2 135 375 1950 3225 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 1975 3275 1\001 +-6 +6 4275 3075 4800 3300 +4 2 0 50 -1 0 11 0.0000 2 135 375 4650 3225 Task\001 +4 0 0 50 -1 0 9 0.0000 2 105 75 4675 3275 2\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1275 1500 1275 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 5025 1500 5025 3000 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4650 3000 4650 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3975 3075 2400 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2325 3075 3900 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 1 1 1.00 45.00 90.00 + 1 1 1.00 45.00 90.00 + 1950 1200 2550 900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 1 1 1.00 45.00 90.00 + 1 1 1.00 45.00 90.00 + 3750 900 4350 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 1 1 1.00 45.00 90.00 + 1 1 1.00 45.00 90.00 + 2550 2100 2550 900 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 1 1 1.00 45.00 90.00 + 1 1 1.00 45.00 90.00 + 3750 2100 3750 900 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4650 2100 4650 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 2400 1650 3000 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 1650 2100 1650 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2025 3000 2025 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 4275 2400 4275 3000 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 2325 3300 2325 3000 1200 3000 1200 3300 2325 3300 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 5100 3300 5100 3000 3975 3000 3975 3300 5100 3300 +4 1 0 50 -1 0 11 0.0000 2 180 540 3150 1425 locking\001 +4 1 0 50 -1 0 11 1.5708 2 135 360 1200 2250 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 540 4725 2700 dealloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 360 5100 2250 alloc\001 +4 1 0 50 -1 0 11 5.4803 2 135 540 3375 2775 dealloc\001 +4 1 0 50 -1 0 11 0.8029 2 180 780 2700 2625 ownership\001 +4 1 0 50 -1 0 11 0.8029 2 135 540 2925 2775 dealloc\001 +4 1 0 50 -1 0 11 5.4803 2 180 780 3600 2625 ownership\001 +4 1 0 50 -1 0 11 4.7124 2 135 540 4725 1800 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 540 1575 2700 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 540 1575 1800 dealloc\001 +4 1 0 50 -1 0 11 1.5708 2 135 360 1950 2700 alloc\001 +4 1 0 50 -1 0 11 4.7124 2 135 360 4350 2700 alloc\001 Index: doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.bib =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.bib (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.bib (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -34,2 +34,371 @@ year = "2008" } + +@article{Sleator85, + author = {Sleator, Daniel Dominic and Tarjan, Robert Endre}, + title = {Self-Adjusting Binary Search Trees}, + journal = jacm, + volume = 32, + number = 3, + year = 1985, + issn = {0004-5411}, + pages = {652-686}, + doi = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/3828.3835}, + address = {New York, NY, USA}, +} + +@article{Berger00, + author = {Emery D. Berger and Kathryn S. McKinley and Robert D. Blumofe and Paul R. Wilson}, + title = {Hoard: A Scalable Memory Allocator for Multithreaded Applications}, + booktitle = {International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-IX)}, + journal = sigplan, + volume = 35, + number = 11, + month = nov, + year = 2000, + pages = {117-128}, + note = {International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-IX)}, +} + +@inproceedings{berger02reconsidering, + author = {Emery D. Berger and Benjamin G. Zorn and Kathryn S. McKinley}, + title = {Reconsidering Custom Memory Allocation}, + booktitle = {Proceedings of the 17th ACM SIGPLAN Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA) 2002}, + month = nov, + year = 2002, + location = {Seattle, Washington, USA}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@article{larson99memory, + author = {Per-{\AA}ke Larson and Murali Krishnan}, + title = {Memory Allocation for Long-Running Server Applications}, + journal = sigplan, + volume = 34, + number = 3, + pages = {176-185}, + year = 1999, + url = {http://citeseer.ist.psu.edu/article/larson98memory.html} +} + +@techreport{gidpt04, + author = {Anders Gidenstam and Marina Papatriantafilou and Philippas Tsigas}, + title = {Allocating Memory in a Lock-Free Manner}, + number = {2004-04}, + institution = {Computing Science}, + address = {Chalmers University of Technology}, + year = 2004, + url = {http://citeseer.ist.psu.edu/gidenstam04allocating.html} +} + +@phdthesis{berger02thesis, + author = {Emery Berger}, + title = {Memory Management for High-Performance Applications}, + school = {The University of Texas at Austin}, + year = 2002, + month = aug, + url = {http://citeseer.ist.psu.edu/article/berger02memory.html} +} + +@misc{sgimisc, + author = {SGI}, + title = {The Standard Template Library for {C++}}, + note = {\textsf{www.sgi.com/\-tech/\-stl/\-Allocators.html}}, +} + +@misc{dlmalloc, + author = {Doug Lea}, + title = {dlmalloc version 2.8.4}, + month = may, + year = 2009, + note = {\textsf{ftp://g.oswego.edu/\-pub/\-misc/\-malloc.c}}, +} + +@misc{ptmalloc2, + author = {Wolfram Gloger}, + title = {ptmalloc version 2}, + month = jun, + year = 2006, + note = {\textsf{http://www.malloc.de/\-malloc/\-ptmalloc2-current.tar.gz}}, +} + +@misc{nedmalloc, + author = {Niall Douglas}, + title = {nedmalloc version 1.06 Beta}, + month = jan, + year = 2010, + note = {\textsf{http://\-prdownloads.\-sourceforge.\-net/\-nedmalloc/\-nedmalloc\_v1.06beta1\_svn1151.zip}}, +} + +@misc{hoard, + author = {Emery D. Berger}, + title = {hoard version 3.8}, + month = nov, + year = 2009, + note = {\textsf{http://www.cs.umass.edu/\-$\sim$emery/\-hoard/\-hoard-3.8/\-source/hoard-38.tar.gz}}, +} + +@comment{mtmalloc, + author = {Greg Nakhimovsky}, + title = {Improving Scalability of Multithreaded Dynamic Memory Allocation}, + journal = {Dr. Dobb's}, + month = jul, + year = 2001, + url = {http://www.ddj.com/mobile/184404685?pgno=1} +} + +@misc{mtmalloc, + key = {mtmalloc}, + title = {mtmalloc.c}, + year = 2009, + note = {\textsf{http://src.opensolaris.org/\-source/\-xref/\-onnv/\-onnv-gate/\-usr/\-src/\-lib/\-libmtmalloc/\-common/\-mtmalloc.c}}, +} + +@misc{tcmalloc, + author = {Sanjay Ghemawat and Paul Menage}, + title = {tcmalloc version 1.5}, + month = jan, + year = 2010, + note = {\textsf{http://google-perftools.\-googlecode.\-com/\-files/\-google-perftools-1.5.tar.gz}}, +} + +@inproceedings{streamflow, + author = {Scott Schneider and Christos D. Antonopoulos and Dimitrios S. Nikolopoulos}, + title = {Scalable Locality-Conscious Multithreaded Memory Allocation}, + booktitle = {International Symposium on Memory Management (ISSM'06)}, + month = jun, + year = 2006, + pages = {84-94}, + location = {Ottawa, Ontario, Canada}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@misc{streamflowweb, + author = {Scott Schneider and Christos Antonopoulos and Dimitrios Nikolopoulos}, + title = {Streamflow}, + note = {\textsf{http://people.cs.vt.edu/\-\char`\~scschnei/\-streamflow}}, +} + +@inproceedings{Blumofe94, + author = {R. Blumofe and C. Leiserson}, + title = {Scheduling Multithreaded Computations by Work Stealing}, + booktitle = {Proceedings of the 35th Annual Symposium on Foundations of Computer Science, Santa Fe, New Mexico.}, + pages = {356-368}, + year = 1994, + month = nov, + url = {http://citeseer.ist.psu.edu/article/blumofe94scheduling.html} +} + +@article{Johnstone99, + author = {Mark S. Johnstone and Paul R. Wilson}, + title = {The Memory Fragmentation Problem: Solved?}, + journal = sigplan, + volume = 34, + number = 3, + pages = {26-36}, + year = 1999, +} + +@inproceedings{Grunwald93, + author = {Dirk Grunwald and Benjamin G. Zorn and Robert Henderson}, + title = {Improving the Cache Locality of Memory Allocation}, + booktitle = {{SIGPLAN} Conference on Programming Language Design and Implementation}, + pages = {177-186}, + year = 1993, + url = {http://citeseer.ist.psu.edu/grunwald93improving.html} +} + +@inproceedings{Wilson95, + author = {Wilson, Paul R. and Johnstone, Mark S. and Neely, Michael and Boles, David}, + title = {Dynamic Storage Allocation: A Survey and Critical Review}, + booktitle = {Proc. Int. Workshop on Memory Management}, + address = {Kinross Scotland, UK}, + year = 1995, + url = {http://citeseer.ist.psu.edu/wilson95dynamic.html} +} + +@inproceedings{Siebert00, + author = {Fridtjof Siebert}, + title = {Eliminating External Fragmentation in a Non-moving Garbage Collector for Java}, + booktitle = {CASES '00: Proceedings of the 2000 international conference on Compilers, architecture, and synthesis for embedded systems}, + year = 2000, + isbn = {1-58113-338-3}, + pages = {9-17}, + location = {San Jose, California, United States}, + doi = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/354880.354883}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} + +@inproceedings{Lim98, + author = {Tian F. Lim and Przemyslaw Pardyak and Brian N. Bershad}, + title = {A Memory-Efficient Real-Time Non-copying Garbage Collector}, + booktitle = {ISMM '98: Proceedings of the 1st international symposium on Memory management}, + year = 1998, + isbn = {1-58113-114-3}, + pages = {118-129}, + location = {Vancouver, British Columbia, Canada}, + doi = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/286860.286873}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} + +@article{Chang01, + author = {J. Morris Chang and Woo Hyong Lee and Witawas Srisa-an}, + title = {A Study of the Allocation Behavior of {C++} Programs}, + journal = {J. Syst. Softw.}, + volume = 57, + number = 2, + year = 2001, + issn = {0164-1212}, + pages = {107-118}, + doi = {http://dx.doi.org/10.1016/S0164-1212(00)00122-9}, + publisher = {Elsevier Science Inc.}, + address = {New York, NY, USA} +} + +@article{Herlihy93, + author = {Maurice Herlihy}, + title = {A Methodology for Implementing Highly Concurrent Data Objects}, + journal = toplas, + volume = 15, + number = 5, + year = 1993, + issn = {0164-0925}, + pages = {745-770}, + doi = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/161468.161469}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} + +@article{Denning05, + author = {Peter J. Denning}, + title = {The Locality Principle}, + journal = cacm, + volume = 48, + number = 7, + year = 2005, + issn = {0001-0782}, + pages = {19-24}, + doi = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/1070838.1070856}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} + +@misc{wilson-locality, + author = {Paul R. Wilson}, + title = {Locality of Reference, Patterns in Program Behavior, Memory Management, and Memory Hierarchies}, + url = {http://citeseer.ist.psu.edu/337869.html} +} + +@inproceedings{Feng05, + author = {Yi Feng and Emery D. Berger}, + title = {A Locality-Improving Dynamic Memory Allocator}, + booktitle = {Proceedings of the 2005 Workshop on Memory System Performance}, + location = {Chicago, Illinois}, + publisher = {ACM}, + address = {New York, NY, USA}, + month = jun, + year = 2005, + pages = {68-77}, +} + +@inproceedings{grunwald-locality, + author = {Dirk Grunwald and Benjamin Zorn and Robert Henderson}, + title = {Improving the Cache Locality of Memory Allocation}, + booktitle = {PLDI '93: Proceedings of the ACM SIGPLAN 1993 conference on Programming language design and implementation}, + year = 1993, + isbn = {0-89791-598-4}, + pages = {177-186}, + location = {Albuquerque, New Mexico, United States}, + doi = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/155090.155107}, + publisher = {ACM Press}, + address = {New York, NY, USA} +} + +@article{Alexandrescu01b, + author = {Andrei Alexandrescu}, + title = {{volatile} -- Multithreaded Programmer's Best Friend}, + journal = {Dr. Dobb's}, + month = feb, + year = 2001, + url = {http://www.ddj.com/cpp/184403766} +} + +@article{Attardi03, + author = {Joseph Attardi and Neelakanth Nadgir}, + title = {A Comparison of Memory Allocators in Multiprocessors}, + journal = {Sun Developer Network}, + month = jun, + year = 2003, + note = {\textsf{http://developers.sun.com/\-solaris/\-articles/\-multiproc/\-multiproc.html}}, +} + +@unpublished{memlayout, + author = {Peter Jay Salzman}, + title = {Memory Layout and the Stack}, + journal = {Using GNU's GDB Debugger}, + note = {\textsf{http://dirac.org/\-linux/\-gdb/\-02a-Memory\_Layout\_And\_The\_Stack.php}}, +} + +@unpublished{Ferguson07, + author = {Justin N. Ferguson}, + title = {Understanding the Heap by Breaking It}, + note = {\textsf{https://www.blackhat.com/\-presentations/\-bh-usa-07/Ferguson/\-Whitepaper/\-bh-usa-07-ferguson-WP.pdf}}, +} + +@inproceedings{Huang06, + author = {Xianglong Huang and Brian T Lewis and Kathryn S McKinley}, + title = {Dynamic Code Management: Improving Whole Program Code Locality in Managed Runtimes}, + booktitle = {VEE '06: Proceedings of the 2nd international conference on Virtual execution environments}, + year = 2006, + isbn = {1-59593-332-6}, + pages = {133-143}, + location = {Ottawa, Ontario, Canada}, + doi = {http://doi.acm.org/10.1145/1134760.1134779}, + publisher = {ACM Press}, + address = {New York, NY, USA} + } + +@inproceedings{Herlihy03, + author = {M. Herlihy and V. Luchangco and M. Moir}, + title = {Obstruction-free Synchronization: Double-ended Queues as an Example}, + booktitle = {Proceedings of the 23rd IEEE International Conference on Distributed Computing Systems}, + year = 2003, + month = may, + url = {http://www.cs.brown.edu/~mph/publications.html} +} + +@techreport{Detlefs93, + author = {David L. Detlefs and Al Dosser and Benjamin Zorn}, + title = {Memory Allocation Costs in Large {C} and {C++} Programs}, + number = {CU-CS-665-93}, + institution = {University of Colorado}, + address = {130 Lytton Avenue, Palo Alto, CA 94301 and Campus Box 430, Boulder, CO 80309}, + year = 1993, + url = {http://citeseer.ist.psu.edu/detlefs93memory.html} +} + +@inproceedings{Oyama99, + author = {Y. Oyama and K. Taura and A. Yonezawa}, + title = {Executing Parallel Programs With Synchronization Bottlenecks Efficiently}, + booktitle = {Proceedings of International Workshop on Parallel and Distributed Computing for Symbolic and Irregular Applications (PDSIA '99)}, + year = {1999}, + pages = {182--204}, + publisher = {World Scientific}, + address = {Sendai, Japan}, +} + +@inproceedings{Dice02, + author = {Dave Dice and Alex Garthwaite}, + title = {Mostly Lock-Free Malloc}, + booktitle = {Proceedings of the 3rd international symposium on Memory management (ISMM'02)}, + month = jun, + year = 2002, + pages = {163-174}, + location = {Berlin, Germany}, + publisher = {ACM}, + address = {New York, NY, USA}, +} Index: doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.tex =================================================================== --- doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.tex (revision 1cf8a9f58b4024fe0c4041b96f9b4317a00baa51) +++ doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.tex (revision 5cefa433745f174ac307ad32f414eb2fef7476a2) @@ -85,4 +85,5 @@ \usepackage{comment} % Removes large sections of the document. \usepackage{tabularx} +\usepackage{subfigure} % Hyperlinks make it very easy to navigate an electronic document. @@ -168,5 +169,6 @@ %\usepackageinput{common} \CFAStyle % CFA code-style for all languages -\lstset{basicstyle=\linespread{0.9}\tt} % CFA typewriter font +\lstset{basicstyle=\linespread{0.9}\sf} % CFA typewriter font +\newcommand{\uC}{$\mu$\CC} \newcommand{\PAB}[1]{{\color{red}PAB: #1}} @@ -224,5 +226,5 @@ \addcontentsline{toc}{chapter}{\textbf{References}} -\bibliography{uw-ethesis,pl} +\bibliography{pl,uw-ethesis} % Tip: You can create multiple .bib files to organize your references. % Just list them all in the \bibliogaphy command, separated by commas (no spaces).