wyant@saber.com (06/05/91)
This may have been discussed before, so pardon me for raising it again if it has been. It has been observed that allowing the user to write specialized allocators and deallocators for classes of objects that share similiar lifetimes can improve performance. Mesa and Cedar supported this with the notion of 'zones'. Lisp environments have something similiar; and C++ allows one to overloadthe 'new' and 'free' operators to provide type-specific allocators/deallocators. I don't see such support in Modula-3. I guess my question to the Modula-3 designers would be: is the trend to move away from such mechanisms and have more intelligent garbage collectors (generational or temporal). Has anyone found this to be a problem in developing Modula-3 applications. Not having seen Trestle, how has garbage collection interacted with the need to create lightweight UI objects fairly rapidly ? Any studies on this ? Ever curious (in more then one sense :-)) Geoff Wyant wyant@saber.com
moss@cs.umass.edu (Eliot Moss) (06/06/91)
Well, we're working on a pretty flexible (and we trust fast) generational collector for our Modula-3 system, and making good progress. Allowing user defined allocators would be complex, and I'm not sure it would be all that much help (with the obvious exception of user written routines for managing the UNTRACED area(s)). We may extend our collector to support finalization, but that would be a ways down the road. Eliot -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
muller@src.dec.com (Eric Muller) (06/06/91)
In article <9106051432.AA22607@riposte>, wyant@saber.com ask about
specialized allocators and deallocators.
The Modula-3 language does not offer direct support for that. However,
in SRC Modula-3, the runtime is written in Modula-3 and we give the
source. In particular, the interfaces RTHeap and RTHeapRep, and the
module RTHeap that implements them, are concerned with traced heap
management.
There is nothing that prevents a program from using an alternative
implementation of RTHeap. This implementation could treat the
allocation requests differently based on the typecode of the referent
to allocate. It could also receive hints from the program, also based
on typecodes. It is also conceivable to use the current system for
some typecodes, and another one for other typecodes.
The current collector would not support very well 'free' methods, as
detecting the deallocated objects would imply a sweep of the heap.
--
Eric.