[squeak-dev] Maintenance of remote references
Michael van der Gulik
mikevdg at gmail.com
Wed Jul 30 06:37:22 UTC 2008
On Fri, 18 Jul 2008 14:09:37 -0300
"Sebastian Sastre" <ssastre at seaswork.com> wrote:
> Hi there,
>
> Thing. I'm working in the RemoteObjects package that is a sort of RMI or
> RPC but for real objects ;) Right now is working > x2 than rST in localhost. It
> was designed in a P2P fashion and it allows to have N brokers even inside the
> same image.
>
> Purpose. Scaling Squeak today.
What do you mean by "Scaling Squeak"?
Are you talking about being able to scale the image on a single machine with multiple CPUs? Or scaling an image to run on a cluster of servers? Or are you talking about a wide-area distributed network of some sort?
If this is a business requirement, you could look at GemStone.
> Problem. A broker can publish some objects but, as the communication get
> used, remote references start to be holded by them. Thats fine until you think
> in how to claim space without injecting troubles.
This is a field of research in distributed systems: "Distributed Garbage Collection".
One algorithm would be to use backtracing GC. Essentially, every remote object contains a list of other remote objects that refer to it. It then becomes possible to determine whether a given object is garbage by tracing back through all of the backpointers to see if you can reach a known non-garbage object. Loops can be detected by marking the objects somehow. This GC algorithm can also have multiple garbage collectors running on it concurrently.
Gulik.
--
Michael van der Gulik <mikevdg at gmail.com>
More information about the Squeak-dev
mailing list
|