On Tuesday 02 April 2002 08:30, Peter Gibbs wrote: > > Currently, string_make sets the value of buflen. It does not know about > Parrot_allocate's rounding rule, so it uses the supplied size. The patch > below changes string_make to set the allocation request (and hence buflen) > to one less than the next multiple of 16; thus a zero allocation will end up > with a buflen of 15. This looks to be the best that can be done simply.
Thanks for the patch. However..... We should probably have Parrot_allocate (and realloc) actually pass back how much it *really* allocated, as opposed to having to guess and/or reimplement the rounding algorithm everywhere. Either buflen = Parrot_allocate(interpreter, requested_size, &bufstart); or bufstart = Parrot_allocate(interpreter, requested_size, &buflen); or something else similar. > > > > Parrot_go_collect uses a slightly different rounding rule, and will > > allocate > > > zero bytes to a zero-length buffer; the current allocation address will > be > > > placed in bufstart, but the same address will be used for the next > buffer > > > collected. > > > > They should probably round the same. > > The patch below changes the GC code to use the same rounding algorithm as > Parrot_allocate i.e. round up to next multiple of 16. The above would solve the GC problem, too. A requested reallocation of buflen * 1.2 that also returns a size already rounded to 16 would cause everything to be already aligned, eliminating the need to have to round when walking. Again, it's probably best to bury this within the alloc calls themselves, so that the algorithm is best encapsulated. Thoughts? -- Bryan C. Warnock [EMAIL PROTECTED]
