[ruby-talk:6906] Re: xmalloc(), xfree()

On Fri, 10 Nov 2000, Yukihiro Matsumoto wrote:
> Hi,

Hi (4 weeks later)

> In message "[ruby-talk:6192] Re: xmalloc(), xfree()"
>     on 00/11/09, Mathieu Bouchard <[e-mail]> writes:
> |No-one replied. I'm trying again with another question: what do you think
> |is best:
> |	* leave malloc/free as-is, make ruby use xmalloc/xfree;
> Tell me the detail for this.

This means that xmalloc must be used with xfree and malloc with free. The
two wouldn't mix. This allows Ruby to use a custom allocator, which in
turn can use malloc(). 

> |	* make ruby use our own malloc/free;
> Do you mean re-implementing malloc/free by ourselves?  I think it's
> too tough job to achieve time/space efficiency like system's own.  I
> don't think it's worth it.

This could start by getting either the GLIBC one or the Perl one. Another
possibility is to try to reuse the one of the available C library
using a dynamic symbol lookup trick so that C's malloc() does not conflict
with Ruby's malloc().

> |size_t xmsize (void *ptr);
> |"returns the number of bytes allocated by the malloc
> |operation that returned ptr. might be larger than the size
> |originally asked for."
> Is this REALLY worth it?  It might introduce potential crash by
> free()'ing xmalloc()'ed memory.  I'm afraid to dream a nightmare.

The optimisation I wanted to add was to make basic classes aware of how
much memory they did allocate. This takes into account the fact
that several allocators have fixed sizes for allocation (for
example, based on powers of two or smaller numbers; or based on
fibonacci and related series; or even just multiples of 16)

That way you can avoid bogus reallocs (that might not do anything) and the
general waste of memory because of sync issues between requested sizes and
available sizes. For example, Ruby commonly has array sizes in powers of
two. There is an allocator (Perl's optional allocator) has alloc sizes in
powers of two minus a word size, which means on average you use 40% of the
space instead of 70% (and waste the rest).

This is however not a pressing matter right now. 

Another thing I had planned is to remove the "capacity" field from Array,
because it can be get with xmsize(). this frees up a field which could
have been used to make shift/unshift in O(1) average time instead of O(n).
(Doing so without removing capacity means relacing two fields by a pointer
to an array of two fields, kind of ugly).

But as you see I don't consider these to be of incredible importance. I
wanted to tell those reasons to you in case it gives you some ideas. I'll
reconsider once Ruby 1.8 is out.

OTOH, I had a patch that prepared the way for a future change. it
included:

static long rb_ary_capa(ary);
static long rb_ary_realloc(ary,capacity,offset);

where the latter is interesting because it cleans up array.c a bit
(without changing behaviour). My idea was to put reallocation code in one
place, so that it is more configurable (instead of hardcoding *2, *3 all
over). My patch does half of it. I don't know how much array.c has changed
since 1.6.2 though.

matju