On Sat, 24 Sep 2011 00:09:41 -0400, dsimcha <dsim...@yahoo.com> wrote:
On 9/23/2011 11:51 PM, Robert Jacques wrote:
On Fri, 23 Sep 2011 23:30:34 -0400, dsimcha <dsim...@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
<jmdavisp...@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.
