Vote on region allocator

[dsimcha]

On 9/23/2011 11:51 PM, Robert Jacques wrote:
> 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

You make an interesting point.  One concern, though, is e.g. 
RegionAllocator, where scan vs. no scan has to be set on creation.  I 
don't want to force this to be specified again on allocation, and then 
have to throw an exception or something if it doesn't match.