On Apr 21, 2007, at 8:24 PM, chromatic wrote:
Parrot_alloc_context() performs some calculations about the number of
registers used to determine how much memory to allocate:
const size_t size_n = sizeof (FLOATVAL) * n_regs_used[REGNO_NUM];
const size_t size_nip = size_n +
sizeof (INTVAL) * n_regs_used[REGNO_INT] +
sizeof (PMC*) * n_regs_used[REGNO_PMC];
size_t reg_alloc = size_nip +
sizeof (STRING*) * n_regs_used[REGNO_STR];
Then it calculates a slot value:
const int slot = (reg_alloc + 7) >> 3;
reg_alloc = slot << 3;
This is where I start not to understand. Why reg_alloc + 7? Why
shift left
and right by 3?
I'm not sure if it is actually doing anything that needs to be that
complicated to code that way. It could be able to be written as:
const int slot = (reg_alloc + 7) / 8; /* divide by eight for some
reason and round up on remainder */
reg_alloc = slot * 8; /* reg_alloc is now evenly divisible by 8 */
The difference is that if any of the last three bits are set, the +7
will let it round up, whereas without it it would round down. That's
what it does, don't ask me why(other than maybe guaranteeing
alignment?). Might be using eight for an eight byte int, but if so, it
should be using sizeof(void *) instead, I'm assuming would have been
used. Now, slot is multiplied by sizeof(void*) later on, which may be
why it's divided by eight in the first place.
The n = slot + 1 I find a little odd, because the number is already
rounded up, so it's rounding up and then adding an extra place of
memory.
It gets less clear. The interpreter holds a structure for context
memory with
a free list (an array of void pointers) and the number of free slots,
presumably in this list.
After all of that calculation of slot, the function uses it as an
index into
the free list.
I don't understand that at all.
I do understand the purpose of the resizing code, but not how slot
relates to
it:
if (slot >= interp->ctx_mem.n_free_slots) {
const int n = slot + 1;
int i;
interp->ctx_mem.free_list = (void **)mem_sys_realloc(
interp->ctx_mem.free_list, n * sizeof (void*));
for (i = interp->ctx_mem.n_free_slots; i < n; ++i)
interp->ctx_mem.free_list[i] = NULL;
interp->ctx_mem.n_free_slots = n;
}
This is doubly weird because when Parrot initializes the free list in
create_initial_context(), it allocates a small number of free slots:
#define INITIAL_FREE_SLOTS 8
interp->ctx_mem.n_free_slots = INITIAL_FREE_SLOTS;
interp->ctx_mem.free_list =
(void **)mem_sys_allocate(INITIAL_FREE_SLOTS * sizeof (void
*));
for (i = 0; i < INITIAL_FREE_SLOTS; ++i)
interp->ctx_mem.free_list[i] = NULL;
The result is that the free_list extends quite a bit over the initial
allocation, but it's mostly just an array of null. It's fairly sparse
apart
from that.
Here's another curious thing when allocating a context:
ptr = interp->ctx_mem.free_list[slot];
old = CONTEXT(interp->ctx);
if (ptr) {
interp->ctx_mem.free_list[slot] = *(void **) ptr;
}
I wish I could tell you what the assignments to and from ptr do here,
but I
can't, nor what they signify. There's a similar form to free a
context:
ptr = ctxp;
slot = ctxp->regs_mem_size >> 3;
assert(slot < interp->ctx_mem.n_free_slots);
*(void **)ptr = interp->ctx_mem.free_list[slot];
interp->ctx_mem.free_list[slot] = ptr;
The *(void **) has been confusing me for a long time. It's also in
smallobject.c where a seg fault sometimes happens. But I've never been
able to find out how to decipher it. I can look at the dump of it with
`objdump -dS src/gc/smallobject.c` but still get lost in it
all(although looking at assembly, even intermixed with source code,
requires a little too much of an understanding of the machine to figure
out).
I originally thought the free_list was an array of recycled contexts
to avoid
malloc() and free() pairs by reusing already-allocated-but-unused
memory, but
now I can't tell what it's doing. I tried to change this into a
linked list,
but that failed with invalid reads.
I thought it was a list of items to be freed, but that may be a
different free_list sadly. We have more than one in parrot.
My best guess is that this is an odd way to store contexts of a
specific size
in an array structure so that they're reusable with our new
variable-sized
register sets... but the code is unclear and undocumented. I think
it's also
leaking memory.
Enable the context alloc and free, but probably change what's printed
to make it easy to run through sort, and it might help, maybe.
I'd like to find a simpler scheme, if it's possible. Otherwise, I'd
like to
figure out what's going on so we can at least explain it somehow.
-- c
Rule one of writing in C for a project for many people to code,
document the (you decide the explicative) out of it.
