[Gc] Re: New API function (GC_objdup)

Bruce Hoult bruce at hoult.org
Thu Dec 5 18:14:28 PST 2013


I've changed my mind a little :-)

While I do still want this functionality, I now also want to be able to
allocate a new object of the same allocation kind
(collectable/uncollectable, atomic/full of pointers) as an existing object,
but different size. In order, for example, to be able to write a generic
subarray operation that works correctly and automatically for arrays of
pointers or arrays of immediate values such as integers or characters.

There are no doubt other useful things that people might also want to be
able to do.

The fundamental problem here is that there is no public API to find out the
allocation kind of an object.

There is an internal code for this (a char), but that encoding shouldn't be
exposed as it is arbitrary and could change. What I think would make more
sense is to have a function that returns the allocation function for that
kind of memory.

It would also make sense to return the (rounded up) allocated size of the
object at the same time, as both may well be wanted, both are available in
the block header, finding the block header is somewhat expensive, and the
cost of returning the size as well is minimal.

So I propose GC_alloc_fn GC_alloc_fn_and_size(void *obj, size_t *sz) such
that the user can then implement my original GC_objdup() proposal
themselves as:

size_t sz;
GC_alloc_func alloc = GC_alloc_fn_and_size(oldObj, &sz);
void *newObj = alloc(sz);
memcpy(newObj, oldObj, sz);

The implementation of GC_alloc_fn_and_size() is straightforward, being a
combination of GC_size() and a version of GC_generic_or_special_malloc()
that returns the allocator function instead of calling it.

I'm conscious that the public API that needs to be supported in future
should be as small as practical, but this seems to me to fill a pretty
important hole.

You can view or merge this change from:

https://github.com/brucehoult/bdwgc/tree/get_alloc_fn



On Wed, Dec 4, 2013 at 9:26 PM, Ivan Maidanski <ivmai at mail.ru> wrote:

> Hi Bruce,
>
> The idea looks good to me. Does anyone have an idea how to have the
> requested functionality w/o adding a new function to GC?
> Anyway, please provide a link to your commit on github (it would simplify
> contribution process).
>
> Thank you
>
> Wed, 4 Dec 2013, 10:40 +13:00 from Bruce Hoult <bruce at hoult.org>:
>
>   Hi Ivan,
>
> ..., for something I'm doing at the moment I feel a need for a function
> similar to GC_realloc(), except it doesn't free the old object (and doesn't
> change the size).
>
> I'm calling it GC_objdup(), to parallel GC_strdup() and GC_strndup().
>
> This can be easily implemented by the user by GC_size(); GC_malloc();
> memcpy() except that I want the new object to be the same kind
> (normal/atomic etc) as the original. There doesn't seem to be a public API
> to get the object kind. GC_realloc() does the right thing in this regard.
>
> It's *possible* to get the effect I want from GC_realloc() by building the
> gc with IGNORE_FREE defined. Unfortunately this also changes the behaviour
> of free() if REDIRECT_FREE is defined, although this doesn't matter to me.
>
> How would you feel about adding GC_objdup() to the API if I submitted a
> patch for it?
>
> Bruce
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and is
> believed to be clean.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20131206/5fafe5d6/attachment.htm


More information about the Gc mailing list