[D-runtime] Proposed changes to GC interface

[Sean Kelly]

Resurrecting this discussion in light of precise scanning.  There was some discussion following this message which may be worth reviewing.  Also please note that the user-visible interface may use templates, so the actual implementation may be something like:

struct GC
{
    void* alloc(T)()
    {
        // get pointer map for T
        // call gc_alloc() with pointer map, etc.
    }
}

There's also no reason the compiler runtime couldn't call the GC via this interface rather than how it currently calls the C routines directly.  That convention is a bit outdated and simply hasn't been changed because the current approach works.

On Aug 6, 2010, at 11:59 AM, Sean Kelly wrote:

> I've been thinking about how best to address the problem that the GC currently doesn't finalize structs in conjunction with tracking append metadata, precise scanning, etc.  The current pertinent GC interface is roughly as follows:
> 
> extern (C) void*   function(size_t, uint) gc_malloc;
> extern (C) BlkInfo function(size_t, uint) gc_qalloc;
> extern (C) void*   function(size_t, uint) gc_calloc;
> extern (C) void*   function(void*, size_t, uint ba) gc_realloc;
> extern (C) size_t  function(void*, size_t, size_t) gc_extend;
> extern (C) size_t  function(size_t) gc_reserve;
> extern (C) void    function(void*) gc_free;
> 
> What I'd like to do is this:
> 
> extern (C) void*   function(TypeInfo) gc_alloc;
> extern (C) void*   function(TypeInfo, size_t) gc_allocn;
> extern (C) size_t  function(void*, size_t, size_t) gc_extend;
> extern (C) void*   function(size_t, uint) gc_malloc;
> extern (C) size_t  function(size_t) gc_reserve;
> extern (C) void    function(void*) gc_free;
> 
> // reevaluate
> extern (C) size_t  function(void*, size_t, size_t) gc_extend;
> 
> // deprecate
> extern (C) void*   function(void*, size_t, uint ba) gc_realloc;
> extern (C) BlkInfo function(size_t, uint) gc_qalloc;
> 
> gc_alloc() and gc_allocn() would become the default GC allocator routines and would set any necessary flags based on the supplied type, store the pointer bitmap, initialize the block based on ti.init[], etc.
> 
> gc_malloc() will remain as-is because I suspect there will always be a need for using D as a "better C."  If this becomes an array of structs the user would be responsible for supplying the TypeInfo later (or finalizer or whatever).
> 
> gc_qalloc() should be rendered largely useless by the addition of gc_alloc() and gc_allocn(), since the need for gc_qalloc() was mostly to efficiently do stuff in lifetime.d that would instead be handled by the GC.  Steve, is this accurate?
> 
> gc_realloc() has never seen much use and promises to become increasingly more complicated as TypeInfo is added, etc.  I'd prefer to just drop it and let the user call gc_extend() if he wants to resize memory in place.  This would require allowing gc_extend() to be used on sub-page sized blocks, but this seems reasonable anyway.  If I have a 150 byte array in a 256 byte block I should be allowed to extend it to 256 bytes.  Doing so is basically a no-op, but it frees the user from having to query the block size to determine how to handle an array append operation, for example.
> 
> Finally, I really want to change the APPENDABLE bit to NO_APPEND/STATIC/SINGLE/whatever since the default (zero value) behavior should be that an allocated block is not an array.
> 
> Thoughts?
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime