Ah great! I knew something weird was going on. It will be much easier to detect possible semaphore leakage once the VM itself stops leaking them. On 14 February 2012 22:38, Igor Stasenko <siguctua@gmail.com> wrote:
Just in time.
Before leaving home last week Friday, i sketched things to be checked on next week. And one of them was: - turning an external semaphore table to hold semaphores weakly.
The problem that currently a Smalltalk externalSemaphoreTable is an Array, means that even if in the rest of image nobody points to some semaphore in that array, it will be not GCed unless someone will cleanup the entry there.
Now the reasons why certain semaphores are leaked (and not cleaned up in external semaphore table) could be different, like abnormal process termination, forgetting putting #ensure: etc. But by making that array to be weak array we can make sure that it won't overflow with garbage which no-one uses.
And of course if it overflows because those semaphores is actually used, then its another story.
On 14 February 2012 22:01, Milan Mimica <milan.mimica@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
-- Best regards, Igor Stasenko.
-- Milan Mimica http://sparklet.sf.net