Tradeoffs with resources

[barmar@Think.COM (Barry Margolin)]

    Date: Fri, 21 Sep 90 11:11:52 EDT
    From: CarlManning@ai.mit.edu

       Date: Thu, 20 Sep 90 23:35:30 EDT
       From: barmar@think.com

       It often makes sense to use areas along with resources.  Resource object
       constructors probably shouldn't allocate in ephemeral areas, since their
       lifetimes aren't consistent with the assumptions that EGC is optimized for.

    E.g., it may help improve the locality of objects in a resource, so
    searching through them is less likely to produce page faults (but
    hopefully your search function won't have to be very picky).

I actually wasn't talking about locality in this context, I was talking
about the point you make in the following paragraph.

    Another usage pattern: If problems are being caused because large
    numbers of your objects are outliving the EGC generations and must be
    dynamically GC'd, it may make sense to put them in a different area
    and perhaps adjust the EGC parameters for that area.  I think this
    kind of strategy may be as effective as using resources in this
    situation.  (But I admit I'm speculating; I don't have an actual
    experience with this one.)

You probably don't want to do *any* EGC on the area containing the
objects managed by the resource.  By definition, objects in resources
are long-lived, and EGC is optimized for short-lived objects.  If you
allocate a resourced object in an ephemeral area you're just wasting the
EGC's time.

                                                barmar