uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: small memory footprint tradeoff configuration
Date Fri, 13 Mar 2009 21:04:16 GMT

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

View raw message