🚀 go-pugleaf

I'm just concerned about the garbage collector collecting more than
necessary or leaving around pockets of memory than cannot be used
(memory leaks) when a client in a distributed system crashes. This is
just a concern, I have not experienced any problems like these yet. Has
anyone a better idea on how garbage collection is handled when stubs and
skeletons are involved? The feature is difficult to test and reproduce
when it occurs. The distributed system can be RMI or CORBA based...

Assume the following scenario: An applet contains a pointer to a remote
object (i.e., a stub, which somehow is connected to a skeleton on the
server side). The skeleton points to a server object and facilitates the
data communication between server and client (marshalling and stuff).

Assume now that the gc on the server kicks in. How does it know not to
free the skeletons? As long as there is a client pointing to it, gc
should leave it alone. I assume there is nothing pointing to them from
the server side, but if I'm wrong then this is the answer. On second
thoughts, there must be a skeleton table that contains pointers to all
skeletons. Any insight?

Assume now that the client crashes and the pointer from the client to
the server disappears. Will the skeleton ever be garbage collected? It
should. Does the server know that the client is no longer there such
that to mark the skeleton as not used? If the skeleton is not garbage
collected this is equivalent to a memory leak... Any ideas?

Vladimir


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---