GC leak?

[Jerry James]

On Feb 1, 2008 3:56 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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.

It's the only sane model for a garbage collected system where you are
not imposing a particular garbage collection algorithm.  Think about
defining a time when a finalizer MUST be run and the object garbage
collected.  It's too dependent on the design of the garbage collector.
 A generational GC, for example, will answer that question much
differently from a mark-and-sweep GC.

> 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.

Stop me if I'm wrong, but don't we already flush all streams on exit?
As long as all data has been pushed into the OS layer, it doesn't
matter if the OS or the application does the actual closing.  In fact,
I'll go so far as to claim that we don't need guaranteed finalizer
runs at all, as long as we guarantee that all streams are flushed.

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

Java doesn't.  You can't use finalizers for guaranteed cleanup
purposes.  You use try { ... } finally { ... } blocks to do that.  I
don't know RnRS well enough to say.

> 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.

I don't think we need to do this.

> 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. :-)

Wow, deja vu all over again.  I'll have to fork this off as a separate
thread, or maybe even take it private if nobody else cares, but that
parenthetical remark really resonates with me.  I've had idle dreams
for several years now of ways in which I'd like to transform the
design of XEmacs.  I've even sketched up primitive designs for some of
them, but haven't had time to take them any farther.  For example,
I've considered a file block caching system to deal with large files,
a layered "view" of data with well-defined transformers up and down so
that it is easy, for example, to switch between a hex view (no hexl
needed!), a character view, and a display view of an HTML file, and
allow edits in any view to propagate to the others.  Separating the
data handling piece from the presentation piece(s) was something I
considered as well.  You could attach to a single instance from a TTY,
a GNOME session, etc. without having to "blend" the displays like we
do now.  And then there's the extension language.  There are so many
to choose from, and ... well, Elisp just doesn't cut it anymore.
Sorry, guys!  In any case, there should be a clean separation of the
extension language from the rest of the application.  (X)Emacs C code
is full of Elisp dependencies.

I've never had time to pursue any of this before, but I find that I
have actual free time now that I'm not an academic.  I've been working
on some other projects that have been waiting for love and attention
[1] [2], but sometime next fall, I should be able to get serious about
some of these ideas.  If they sound threatening, start maneuvering now
to head me off. :-)  In any case, every single one of them will
involve touching gigantic gobs of C and Lisp code, so none of them
will be pulled off quickly.

Footnotes:
[1] http://jjames.fedorapeople.org/
[2] Imagine a C code checker that (1) can parse and reason about
unpreprocessed C code, (2) understands features introduced in C99, and
(3) processes source files in a variety of character encodings.  It's
partially built.  I'll need a few more months to build it up to where
it's minimally usable, and still more time after that to implement all
the features I envision.  If you find yourself drooling over the
thought of working on that code base, let me know and maybe I'll find
somewhere to host it ... right after I decide on the license under
which I want to distribute it.  Choices, choices, ...
-- 
Jerry James
http://loganjerry.googlepages.com/