Milan, try checking whether the number of instances of MaTimer correlate to the number of instances of Semaphore you are seeing.
- Chris On Tue, Feb 14, 2012 at 2:01 PM, Milan Mimica <milan.mim...@gmail.com> wrote: > 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 >
