Milan, On 14 Feb 2012, at 21:01, Milan Mimica 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 There was a semaphore related problem in 1.3 that was fixed some time ago. Doing regular image saves was one of the factors involved. Search the mailing list or issues list for semaphore. Sven
