Xref: utzoo comp.lang.lisp:4532 comp.lang.scheme:2011 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson From: wilson@uicbert.eecs.uic.edu (Paul Wilson) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Scheme as an Algol-like, not Lisp-like, language Message-ID: <1991Feb28.212626.23340@uicbert.eecs.uic.edu> Date: 28 Feb 91 21:26:26 GMT References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> <4234@skye.ed.ac.uk> Date: 26 Feb 91 19:49:09 GMT > From: pcg@cs.aber.ac.uk (Piercarlo Grandi) > [discussion of garbage generation profiles] > Even research in these issues has become unfashionable, like research in > locality of reference, and I can think of precious few contributions in > either field for the past ten years or so. >Just check out the last few L&FP proceedings. The last one was even >in Europe! And that's just for starters... References to relevant recent research can be found in my paper in the March SIGPLAN Notices, "Issues and Strategies in Heap Management and Hierarchical Memories," which is a position paper from the GC workshop at OOPSLA/ECOOP '91. Being a resolutely unfashionable person, I'm doing research on garbage collection, locality of reference, and their interactions. My next paper, to be presented at the next SIGPLAN conference, is on improving virtual memory performance by using better copying traversal algorithms, to cluster data. (Yes, it's been tried before, but I do some different things, and it works very well...) Some other people doing relevant research include Ben Zorn at the U. of Colorado at Boulder, and Doug Johnson at TI, and the MUSHROOM group at the U. of Manchester. >Not to mention that several modern lisps provide stack-consing and >areas, allowing manual storage management if desired. Right. On the other hand, the holy grail for gc folk is to avoid having to do that sort of stuff explicitly the vast majority of the time. There have been great strides toward this with generational garbage collectors -- having a bunch of short-lived data isn't nearly as expensive as it used to be, though it's still more expensive than stack allocation. I suspect a bit of lifetime analysis in compilers could help a lot too. -- PRW Paul R. Wilson Software Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@bert.eecs.uic.edu Box 4348 Chicago,IL 60680 -- Paul R. Wilson Software Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@bert.eecs.uic.edu Box 4348 Chicago,IL 60680