Re: GC leak?

On Feb 1, 2008 3:56 PM, Stephen J. Turnbull <stephen(a)xemacs.org&gt; 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, ...