Thilo Goetz 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. > +1 I missed that deduction ;-) > The FSs that were created by the app, for example, would never > be garbage collected, so those references would stay valid until > the end. > true. I don't think this would be a significant issue.
This topic seems to have come to a pretty good concensus: Control GC overall by some configuration parameter - default to operate without it. Have it occur after some component (primitive or aggregate) per some (new?) spec to enable it. Only have it affect things added by that component - preserving IDs that surrounding components may be holding on to Have it occur only if there is some likely gain from spending the time to do it (if this can be figured out without much time overhead). Please correct if this isn't your understanding of the approximate concensus :-) . -Marshall > --Thilo > > >> -Marshall >> > > > >
