This is more of a GC theory question perhaps, but I do have practical
problems, so: I'm trying to figure out how come my headless Pharo 1.3 image
with fairly recent Cog running Magma ran out of Semaphores. I know there is
a fixed limit on number of semaphores Cog can handle, and only Magma and
RFB server have been running on this image for two months, and there wasn't
any heavy load whatsoever, so something must be leaking semaphores - or
more likely - something must be leaking objects having reference(s) to
semaphore(s). I am not leaking sockets btw.

At the moment there is about 1400 instances of Semaphore class, and around
400 after GC.
So first question is: Suppose I haven't run GC manually, could the
semaphore limit be hit?

400 is still too high for a idling image, don't you think?

Anyway, what I try next is to shut down Magma completely and try to clean
the memory by hand. I notice some MaServerSockets are still floating around
so I track the pointers and I find that all the references are circular!
Question two: Does Pharo's GC solve circular references? If yes, how good
is it at it?

But then, thinking more about it, the whole running image is one big graph
of circular references, you wouldn't want the GC to clean that :) So how
does it really work? That's my naive view anyway.

After I wrote all this I figure I'm better of taking a fresh new image and
load what I need into it, even if I have to do it every two months. Not
saving the image is also an option. Yeah, I think I'm going to do just
that. I found my solution, at least this e-mail served for something. Since
I don't have a blog I'll send it anyway.


-- 
Milan Mimica

Reply via email to