gc-by-area and host uptimes

["David L. Andre" <DLA%jasper.scrc.symbolics.com@RELAY.CS.NET>]

Sorry for the late response; I've been a bit behind on my mail recently.

I certainly agree that a mark-sweep GC would be good, for all the reasons you
suggest and more.  I didn't mean to imply on any previous message anything to
the contrary.  In fact, we have had serious discussions on offering a
mark-sweep GC as part of a release.  It's one of many, many such discussions.
We really don't want to offer it in its current state, however, since the
quality is well below that of Ephemeral and Dynamic GC, to the point of being
unusable.  And currently, we don't have resources to test and fix it.

The reality of it all is that Symbolics can't do everything, at least not
this year.  In fact, we can't do more than a small fraction of what is being
discussed.  The challenge is to carefully choose what we do to gain the most
benefit for the least amount of work.  In the course of making these decisions
we weigh highly the input given on SLUG.  At the same time, we try not to
make commitments or set unrealistic expectations.

I guess what I'm trying to say is:  (1) We definitely hear and appreciate
your input; it keeps us honest.  This goes for all discussions on SLUG, not
just this one.  (2) Please use the SLUG mailing list, particularly for
constructive criticism and suggestions.  (3) Finally, try to understand the
position of the Symbolics people on this list.  We can't make promises.  We
occasionally cannot talk about what you want to hear, for a variety of
reasons.  But we do value your input.

Now, back to GC.  Where do SLUG readers think we should concentrate our
efforts in GC development?  If you reply to me, I'll redistribute the
survey results to SLUG.

1.  2x performance improvement of ephemeral GC.
2.  2x performance improvement of dynamic GC.
3.  Ivory-specific GC performance improvements
4.  3600-specific GC performance improvements
5.  CLOE-specific GC performance improvements
6.  Finer control of what gets GC'd (improvement to GC :Immediately By-Area)
7.  Capability to automatically run dynamic GC every 4am, etc.
8.  Better documentation of GC concepts
9.  Better documentation of GC programmer interface
10.  Very Slow, nonincremental Mark-Sweep GC (mainly useful when memory is low) 
11.  Peek mode for GC
12.  Improvments in GC notifications
13.  Better estimations on memory required for GC
14.  Improvement in system performance in the presence of dynamic GC.
15.  Compiled-Function GC.
16.  Improvements in GC user interface.
17.  Improvements in Optimize World
18.  Adaptive object reordering
19.  Improve the interaction of very large objects with GC
20.  Improving "real-time" performance (decreasing the maximum time GC
     can cause an application to "hang")
21.  Improvement to GC programmer interface
22.  Improvement in GC quality and reliability
23.  None of the above -- Symbolics should concentrate on something other than GC
24.  Other suggestions?