1. Effectiveness of an Automatic Insertion of Safe Memory Reuses into ML-like Programs Oukseh Lee and Kwangkeun Yi {oukseh; kwang}@ropas.snu.ac.kr Seoul National University January 12, 2004

2. Question Our SAS 2003 paper* presented  an algorithm to replace allocations by memory reuse (or destructive update); and  some promising yet preliminary experiment numbers. When and how much is it cost-effective?  Space & time-wise.  Before launching it inside our nML compiler. * Oukseh Lee, Hongseok Yang, and Kwangkeun Yi. Inserting Safe Memory Reuse Commands into ML-like Programs. In Proceedings of the Annual International Static Analysis Symposium, volume 2694 of Lecture Notes in Computer Science, pp. 171- 188, San Diego, California, June 2003.

3. Example: insert fun insert i l = case l of [] => i::[] | h::t => if i<h then i::l else let z = insert i t in h::z fun insert b i l = case l of [] => i::[] | h::t => if i<h then i::l else let z = insert b i t in free l when b; h::z 123 4 123 4 result insert 5 l l 5 123 4 result 6

4. Analysis & Transformation Cost 1,500~29,000 lines/sec slope=1.46

5. Reuse Ratio 3.8%~88.6% of allocations are avoided.

6. Memory Peak Reduction 0.0%~71.9% peak reduction much reuse = much peak reduction

7. Difference in Live Cells sieve (85.7%) qsort (83.7%) merge (50.0%) msort (88.6%)

8. Difference in Live Cells k-eval (31.5%)nucleic (17.7%) queens (5.2%) kb (3.8%)

9. Difference in Live Cells life (8.7%) mirage (84.4%)

10. GC-time & Runtime Changes -1.6%~88.5% GC-time reduction -42.9%~25.4% runtime reduction Low reuse ratio: flags overhead High reuse ratio & Small GC-time portion: expansive reuse in the Objective Caml system 5.2% 3.8% -6.0%-6.7% -3.9%-4.9% -3.0%-6.1% -5.0%-7.5% High reuse ratio & Big GC-time portion: runtime reduction 50.0% 83.7% 50.0% 83.7% 88.6% 81.3% 64.5% 71.7% 69.9% 16.0% 17.5% 4.2% 25.4% 50.7% 54.4% 3.4% 10.3% 84.4% 31.5% 5.2% 1.7% 3.9% 1.2% -42.9% -17.1% -21.6% -5.3%

11. GC-time & Runtime Changes much reuse = much GC-time reduction much reuse & big GC-time portion = much runtime reduction

12. Answer program transformation result program performance not much sharing + big GC-time portion runtime speedup high reuse ratio memory peak reduction