Andy Dougherty wrote:
Are you *sure* it's been fixed? My test involved running a simple
program something like this
.sub _main
.local pmc pmc1
pmc1 = new ResizableBooleanArray
pmc1[1000] = 1
.end
and incrementing the '1000'. I found that for every element I added,
parrot allocated 64 extra bytes. (I monitored parrot's calls to malloc()
with -DDETAIL_MEMORY_DEBUG.)
Hence if I want to store 1,000 bits, parrot will call malloc() to
allocate 64,000 bytes. That's why I said it "uses 64 bytes per bit of
information".
I apologize in advance if I have misunderstood the correct way to use
ResizableBooleanArray or what the number '1000' means in the above
example.
Ah, I see what you're talking about. I thought you meant it was taking
up 64 bytes of storage for each bit of data (which it's not).
Yes, ResizableBooleanArray does allocate more memory than it immediately
needs for the number of indexes, anticipating future growth. What the
code is *supposed* to be doing is rounding off to the nearest 64 bits.
newASize = (size / MIN_ALLOC + 1) * MIN_ALLOC;
The first problem is, MIN_ALLOC isn't a simple value macro, it's an
expression, so instead of evaluating as:
newASize = (size / 64 + 1) * 64;
It's evaluating as:
newASize = (size / 8 * 8 + 1) * 8 * 8;
Which gives you a much larger result than intended! Wrapping the
expression in parens takes care of that, but it also means you're
recalculating the value every time you use the macro, so I changed it to
a simple constant:
#define MIN_ALLOC 64
The second problem is, after rounding to the nearest 64 bits, it's
passing the number of bits directly into mem_sys_allocate_zeroed, but
mem_sys_allocate_zeroed (a simple call to calloc) expects bytes.
(FixedBooleanArray doesn't make this mistake, BTW.)
ResizableBooleanArray had another oddity where it was checking to see if
it needed to reallocate based on the literal size, rather than the
rounded size. So, if you stored 1000 bits, and then stored 1001 bits, it
would allocate 1024 bits and then reallocate 1024 bits, instead of just
using the allocated 1024 bits the second time. I fixed that.
In the process, I found a bug in the shift/unshift code. I'll fix that
as a separate commit.
(Joshua, I didn't see your patch until just now. You were close.)
Allison
