uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Lally <ala...@alum.rpi.edu>
Subject Re: small memory footprint tradeoff configuration
Date Fri, 13 Mar 2009 13:58:31 GMT
On Fri, Mar 13, 2009 at 3:07 AM, Thilo Goetz <twgoetz@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.


View raw message