>> Interesting. I thought that the graph calculation was comparatively >> less expensive than compacting the memory.
>Yes, they are. BUT they are done in the cylce of the GC. They are not tracked when the GC is not running. Otherwise all the ref counting would add up to a lot of work. And introduce other problems. Yup. So, what I was wondering was if it would be possible to just run the graph calculation. But I'm hearing you and Ian say - no. > <snip>Why do you need to know this?</snip> > > I cannot determine the lifetime of the objects I am caching (otherwise > I would make them disposable). Many different objects may have picked > up references to them. The cache will periodically be passed an object > that is a different instance, but has the same logical identity as an > object already in the cache. If the cached object is reachable from a > root and it is dirty, then the incoming object is discarded. However, > if the cached object is not reachable from a root, then the incoming > object should replace it. >Why do you care whether it is rooted? If it is STILL THERE in the cache (not collected) then return the instance you do already have. This makes the object rooted again :-) Works like a charm. You "unique" the object when thre is a cached instance. And this the weak reference tells you. The problem with the one in the cache is that it is dirty _and_ not reachable by a root. In other words - nobody wants that one anymore, they made modifications, but then changed their mind. If another instance of the object comes in and it is logically the same from an identity point of view (identity equivalence - not state equivalence), then it should be the one the cache picks up. So - Thanks for the feedback guys. I've altered my strategy on the server so that the cache must be explicitly controlled within a logical thread of execution.
