[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. That’s 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