Full garbage collection throughtout the system.

Lex Spoon lex at cc.gatech.edu
Fri Dec 14 02:00:54 UTC 2001


> Try the attached changes:
> 
> "Change Set:		LessFullGCs-ar
> Date:			12 December 2001
> Author:			Andreas Raab
> 
> Remove the need for garbage collections in two cases.
> 
> Case #1: File operations required (possibly full) garbage collections on
> certain operations. These are unneeded if the file registry does not contain
> a file with the same name. In this case, the failure to perform the
> operation cannot be due to a dangling file handle and thus we don't need a
> GC.
> 
> Case #2: Socket creation required a full GC if the creation failed. This can
> only happen if the number of open sockets is above a critical threshold (and
> therefore exceed OS resources) and some sockets are dangling (and could be
> used to free up resources). A registry threshold can prevent execution of a
> full GC until we have at least a certain number of sockets open.
> "
> 

If only things were this simple.  First, file descriptors can run out,
too.  Second, on Unix, file descriptors and socket descriptors come from
the same pool, and so for example closing a file can mean you now can
open a socket.

Barring tighter OS integration, I think we just have to live with them.

They don't seem that bad, though. First, they only matter during
development -- afterwards, you can put all of the #close's and
#destroy's in manually.  Second, even during development they shouldn't
trigger all that often -- incremental GC will pick up most of them.


Now, Stephen Pair points out that sometimes these GC's will happen when
the problem isn't resources, but something else.  This is hard to avoid
when primitives can't easily say *why* they failed....


-Lex




More information about the Squeak-dev mailing list