Vote on region allocator

[Robert Jacques]

On Sat, 24 Sep 2011 00:09:41 -0400, dsimcha <dsimcha at yahoo.com> wrote:

> 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.
>

Well, that was why I suggested that the allocator type be passed into free/resize as well. So all you have to do if a RegionAllocator is NO_SCAN, is to add/remove a GC region, on allocate(nBytes, GC_SCAN)/resize(...,GC_SCAN)/free(...,GC_SCAN). I think it's safe to say that calling allocate(nBytes,NO_SCAN) and a GC_SCAN region allocator, can be considered a no-op.

Also, you could add a DEFAULT_SCAN to the attributes.