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.

  -Adam

Mime
View raw message