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