On Fri, 23 Sep 2011 23:30:34 -0400, dsimcha <[email protected]> wrote:
On 9/23/2011 11:25 PM, Robert Jacques wrote:
On Fri, 23 Sep 2011 15:53:46 -0400, Jonathan M Davis
<[email protected]> 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
