On Fri, Mar 13, 2009 at 3:07 AM, Thilo Goetz <twgo...@gmx.de> wrote: > Marshall Schor wrote: >> I agree with both of these concepts: only GC'ing things which are not >> in the index and also not reachable from something that is in the index, >> and making GC'ing (mostly) automatic, based on thresholds, etc, when a >> component exits back to the framework. This would be fine for now - if >> use cases come up where some more programmatic control of this is >> needed, we could add something. >> >> Maybe the next thing to focus on is the "contract" re: GC running. For >> a component (primitive or aggregate), the proposed contract is to have >> the GC not change the FS "id"s that existed prior to the component >> running. This is a tradeoff - for more stability with existing handle >> uses, versus less "aggressive" GC's. > > The way I understood it, that was implied by Adam's proposal. > If you only GC FSs that were created since the component was > entered, there is no danger of changing the IDs. Wherever > you actually do GC, you will have to change the FS IDs. GC > without compaction is going to be useless. > > The FSs that were created by the app, for example, would never > be garbage collected, so those references would stay valid until > the end. >
It's certainly possible, but more complicated, to have smarter "handles" that get updated when the underlying FS gets moved in the heap. Of course then the CAS would have to have a record of all the outstanding handles, which it does not now have. But anyway, with my proposal this complication would not be necessary. -Adam
