Matt Dillon <[EMAIL PROTECTED]> wrote:
>
> No waste at all, Alfred, the file descriptor passing code had been
> broken for over 10 years precisely because of its complexity. Rewriting
> the GC to be more efficient essentially requires using deep graph theory
> to locate isolated loops of arbitrary complexity.
Most efficient GCers don't involve much graph theory (the notable
exception is concurrent collectors); instead they rely on various
strategies to drastically reduce the proportion of the arena that they
need to examine in most GC runs. In principle mark-sweep collectors
are as simple as they get, but unp_gc suffers from the interaction
with refcounting.
You can use the idea of scanning less of the arena to improve unp_gc
as follows. I suggest that you keep two additional lists: one of open
unix domain sockets, and one of in-flight sockets. Instead of the
existing breadth-first search of the whole file table at the start of
unp_gc, it should first clear the mark on each descriptor on the
in-flight list, then do a depth-first search of all the descriptors
reachable from the unix domain sockets list, marking each one. The
loop after the big comment in unp_gc should then scan the in-flight
list looking for unmarked descriptors instead of the whole file table.
The descriptor freeing loops stay as they are now.
I think this should solve the problem at hand, i.e. a lock being held
on an important resource while something complicated is being done;
instead you would hold locks on two much less important lists (the
unix domain list and the in-flight list).
> p.s. many object oriented language garbage collectors have the same
> problem. create object A, create object B, A references B, B references A,
> drop A, drop B. A and B still have references and don't get cleaned up.
> Fun.
Most modern GCers don't use reference counting partly for that reason,
and partly because the overhead of maintaining reference counts is too
great.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED]
"Well, as long as they can think we'll have our problems.
But those whom we're using cannot think."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
