Re: [BDW-GC] "Inlined" storage; `scm_take_' functions

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> It’s not such a shame IMO because:
>
>   * You have to allocate anyway, to store the (double) cell, and
>     allocating the whole thing may be just as costly as allocating the
>     cell, at least for small stringbufs/bytevectors.
>
>   * For stringbufs, the user-provided buffer can be reused only if it’s
>     either Latin-1 or UCS-4, anyway.
>
>   * Removing the indirection and using only GC-managed memory is
>     beneficial for Scheme code (which doesn’t use ‘scm_take’).
>
>   * Reusing the malloc(3)-allocated buffer means that we have to
>     register a finalizer to later free(3) that buffer (see, e.g., commit
>     d7e7a02a6251c8ed4f76933d9d30baeee3f599c0), which is costly (see, e.g.,
>     http://www.hpl.hp.com/personal/Hans_Boehm/popl03/web/html/slide_7.html).

All good points.

> That said...
>
>> Did you consider the option of
>>
>> - always having an indirection from the stringbuf/bytevector object to
>> the underlying data
>
> ... this may be valuable (Andy pointed it out as well), at least for
> bytevectors.  The indirection is a requirement for Andy’s
> SRFI-4-on-bytevector patch set, so that ‘scm_take_u8vector ()’ can still
> be supported; it’s also required if we want to provide mmap(3) bindings,
> for instance, that return a bytevector.

OK, cool.  It was actually large bytevectors that I was mostly
thinking about, and IIUC it sounds quite likely that we will end up
keeping meaningful scm_take_... functions there.

> For stringbufs, though, I’m happy if we can leave the code as it is.

Yes, fine.  For stringbufs reallocating feels less painful, especially
given the encoding restriction.

Thanks!
        Neil