Re: [Gc] Re: New API function (GC_objdup)
ivmai at mail.ru
Fri Dec 6 14:33:00 PST 2013
The alternative solution is to expose GC_generic_or_special_malloc() and add GC_kind_and_size(ptr, psize) where kind is either opaque or it could exposed too as macro. Which solution is better?
Anyway, both solutions are better than adding GC_objdup.
Here's why non-functional solution could be better - if you use GC_MALLOC (and GC_DEBUG set), what allocator and size should be returned then? (In case of returning kind we could just define GC_KIND_AND_SIZE and GC_GENERIC_OR_SPECIAL_MALLOC as well as the corresponding GC_debug_ functions)
Sorry, I haven't looked into your patch yet.
Friday, 6 December 2013, 15:14 +13:00 from Bruce Hoult <bruce at hoult.org>:
> 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:
> 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?
> >This message has been scanned for viruses and
> >dangerous content by MailScanner , and is
> >believed to be clean.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc