Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!liuida!mikpe
From: mikpe@ida.liu.se (Mikael Pettersson)
Newsgroups: comp.lang.scheme
Subject: Re: Ports & GC
Message-ID: <1991Apr27.145903.12970@ida.liu.se>
Date: 27 Apr 91 14:59:03 GMT
References: <6260006@otter.hpl.hp.com> <1262@argosy.UUCP>
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 34

In article <1262@argosy.UUCP> freeman@cleo.UUCP (Jay R. Freeman) writes:
> [describes the approach taken in Pixie Scheme]
>I have no idea how other implementations do it, and would be curious
>myself about the answers.

Here's how my Scheme handles garbage ports:

* A port object contains, among other things, a C file-pointer and
  a weak pointer to another port (or NIL).

* When a new port is allocated (by open-{input,output}-file), it's added
  to a "list" (using the weak "next port" ptr) of all ports.

* After each collection, this list is scanned. Surviving ports are
  (re-)linked together by updating their "next port" pointers. Dead
  ports are closed (unless close-{input,output}-port did that before)
  and then forgotten.

A disadvantage of this approach is that the last scanning phase could
exhibit poor locality, touching random pages both in the old and new
heaps. On the other hand, the average number of ports is usually less
than 10 (3-6 seems to be the average in my system) so this is probably
not a serious problem. The advantages or having safe and fast deallocation
of a scarce OS resource are much more important.

(I have seen Lisp/Scheme implementations (mark-sweep based) that would
check, for each dead object, whether it was a port, and if so do the
cleanup action. Not quite what I would call "efficient"..)


/Mike
-- 
Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden
email: mpe@ida.liu.se or ...!{mcsun,munnari,uunet,unido,...}!sunic!liuida!mpe