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. --Thilo > > -Marshall
