GC leak?

[Stephen J. Turnbull]

Jerry James writes:

 > On Feb 1, 2008 1:23 AM, Marcus Crestani
 > <crestani at informatik.uni-tuebingen.de> wrote:
 > > Currently the garbage collector does not run the finalizers when
 > > XEmacs exits.  This is bad, we should definitely fix this.  I see if I
 > > can come up with a patch in the next couple of days.
 > 
 > It isn't necessarily bad.  Java doesn't guarantee that your finalizers
 > will ever be run, for example, so a standards-compliant JVM can behave
 > in exactly the same way.

That's a good way to convince me to do the opposite.  (Sorry, couldn't
resist taking a poke at Java. :-)

Seriously, nor does Scheme AFAIK.  In theory all Scheme objects are
eternal, but you can GC their memory images in a process if there are
no remaining references to them.  You don't have to.

 > And there's really no reason to run finalizers on exit for the vast
 > majority of objects.

True.  However, in many cases we do have external resources needing
finalization (databases and network connections need closing, fds need
flushing, etc), and if we allow the finalizers to do that work and
guarantee that finalizers get run before a normal exit, there's that
much less work that application programmers need to do.

How do Java and RnRS treat such external objects that need finalization?

Surely we can come up with a way to tag certain classes as having
"important" finalizers in that sense, and guarantee that they be run
even at exit.  (Isn't there a class of LRECORD_WITHOUT_FINALIZER
already?)  Or we could separate finalization into a two stage process,
the first stage finalizes external resources, and is always done.  The
second stage finalizes resources that the OS would clean up for us at
shutdown, and can be omitted at shutdown.  But such omission is an
optimization; it can wait if necessary.

 > That will just make XEmacs take longer to shut down all the way.

People who are in a hurry for a given instance to start and stop can
run XEmacs as a server process and do all their editing via gnuclient.
(Really, XEmacs proper should have no UI; all UIs should be clients of
the editor. :-)

 > All this means is that the information reported by valgrind on exit
 > can't be trusted.  That's okay,

IMO guaranteed finalization except for objects that we decide don't
need it is best.  How about

#if !defined(XEMACS_HAS_OPTIMIZED_FINALIZATION_MODEL) || DEBUG_XEMACS
  /* code that guarantees finalization */
#endif

If you really are a speed demon feel free to add the null finalization
model and #define XEMACS_HAS_OPTIMIZED_FINALIZATION_MODEL in config.h
by hand. :-)