Position Paper for OOPSLA'93 Workshop on Memory Management and GC

	David Ungar
	david.ungar@sun.com
	2600 Casey   MS 29-116
	Sun Microsystems Laboratories, Inc.
	Mountain View, CA 94043
	
	Programming language implementations that free the programmer from 
problems caused by dangling references, storage leaks, and lack of 
pointer and type safety boost productivity. In order to realize these 
gains an automatic storage reclamation system is needed. I have been involved
in implementing and designing such systems for Smalltalk-80 and Self 
and have gained a deep respect for several issues:

o  It is not easy to retrofit automatic storage reclamation onto a 
   language or implementation. Language and compiler restrictions and 
   support seem to be needed.

o  Conservative collection algorithms seem to open the door to a devil 
   that automatic collection was supposed to banish: programs behaving in 
   ways that cannot be explained in terms of their source code. It seems 
   possible to suffer storage leaks that cannot be explained without knowing 
   the layout of memory and, say, the bit-wise format of a float.

o  In the future, as interfaces become more interactive and feature 
   more animation, video, and sound, pause times will become more critical 
   and quasi-real time operation more important. How can we achieve this 
   without slowing down program execution too much?

o  Performance sweet-spots can be surprisingly language-dependent. For 
   example, Smalltalk systems do not seem to do well with the same 
   collectors that work for Lisp systems. Is it possible to predict how well 
   a given scheme will travel from one language to another?

o  It is hard to find a task for hardware that cannot be better done 
   with software, yet memory management is one of the few areas where 
   specialized hardware can pay off (e.g. Mushroom), What should we do about 
   influencing hardware designers?

o  Although the vast army of C++ programs can benefit to some degree 
   from add-on collectors or storage-integrity checkers, is it in Computer 
   Science's best interest to provide palliatives that do not remedy the 
   basic disease of a non-pointer-safe language? Would it be better to put 
   the same effort into building programming systems based on more secure 
   languages?

o  Performance devils lurk, and you just cannot know for sure if a 
   scheme will work until it has been deployed in the field and people who 
   write programs in strange ways get a hold of your system. How, then, do 
   you judge the worth of a new idea or test it?

If invited to the workshop, I would be happy to swap war stories about
these, and especially to learn about others' experience with them.