> Interesting. I thought that the graph calculation was > comparatively less expensive than compacting the memory.
It'll depend. If there are no unreachable objects, then it's pretty clear that the graph calculation will take longer, because there will be no compaction... And in general, the fewer objects that actually need collecting, the more the graph calculation time will tend to dominate. (OK, so it's not a straightforward function - the compact cost will vary according how much of the generation being compacted stays still and how much has to move, so it's possible to contrive examples where freeing even a single object makes for a costly compact. But on average, if fewer objects get freed, the compactor will have to move less stuff.) I'm prepared to believe that the graph calculation is usually cheaper than the compact (especially so for a gen 1 or gen 2 compact) but a large part of that will be because the GC algorithms try not to run a collect all that often. I suspect that if you wanted to run 20 heap graph walks a second, the cost of the heap walk might start to dominate... In any case, as far as I know it's not possible to do the first phase of a GC but not the actual compaction. I think you're going to have to come up with a different strategy. I don't really understand what you're trying to achieve to be honest - neither of the two behaviours you described made sense to me, so I must have missed something. You say that when a new object comes in, then either: > If the cached object is reachable from a root and it is > dirty, then the incoming object is discarded. ...so you're throwing away the new incoming data? Or: > However, if the cached object is not reachable from a root, > then the incoming object should replace it. Why bother replacing it if you know it's not reachable? If it's not reachable it's never going to be used again, and will be discarded at the next GC, so it really doesn't matter what you do. Which suggests that you will get away with always doing the first thing in all cases, i.e. to ignore the incoming data. So it sounds like you don't even need to be receiving that data at all, since the two outcomes you describe are (a) ignore the new data or (b) store the new data in a doomed location. So I think I must have missed something... -- Ian Griffiths DevelopMentor > -----Original Message----- > From: Pinto, Ed [mailto:[EMAIL PROTECTED] > > Yes I mean reachable from a root. > > <snip>If it was able to determine whether objects were reachable without > performing a GC, it wouldn't need to do most of the work involved in > performing a GC!</snip> > > Interesting. I thought that the graph calculation was comparatively less > expensive than compacting the memory. > > <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.
