Vote on region allocator

[Robert Jacques]

On Fri, 23 Sep 2011 23:30:34 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> On 9/23/2011 11:25 PM, Robert Jacques wrote:
>> On Fri, 23 Sep 2011 15:53:46 -0400, Jonathan M Davis
>> <jmdavisProg at gmx.com> wrote:
>>
>> No. I cannot build an efficient and safe appender on this API.
>
> The resize() fix you requested is going to get implemented.  I just
> haven't actually added it yet.  The allocate() fix with block
> attributes, however, is not because:
>
> 1.  You can just call addRegion/removeRegion yourself after allocating,
> so it just adds bloat.
>
> 2.  A major purpose of RegionAllocator and probably several other
> allocators is to avoid the GC lock.  I don't want anything that could
> lock to be implicit unless the only alternative is failure.
>

A) If the allocator is the GC, then I've just taken the GC lock twice.
B) If the allocator is stack like, then I might not necessarily need to use addRegion, at least for some internal structures.
C) If region allocator, for example, maintained a second, GC-region segmented stack, then I can have GC tracing without taking the GC lock.

In terms of attributes, you might generalize this to:

NO_SCAN      // I had no pointers
REGION_SCAN  // I have pointers internal to the region
GC_SCAN      // I have pointers to general memory

D) There's performance gains in knowing that REGION_SCAN is equivalent to NO_SCAN or GC_SCAN