GC leak?

[Vladimir G. Ivanovic]

Jerry,

About this XEmacs redesign paper you are thinking of writing... ;-)

Seriously, it would be great if you put your (incomplete) thoughts on 
virtual paper and emailed them to the list. So far the discussion has 
been quite civil, so I don't expect that you'd get any arrows in your 
back.

--- Vladimir

on 02/01/2008 03:31 PM Jerry James said the following:
> 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, ...


-- 

Vladimir G. Ivanovic


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.xemacs.org/pipermail/xemacs-beta/attachments/20080202/ba6cd595/signature.pgp