[Issue 10589] New: GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a certain size

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10589

           Summary: GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a
                    certain size
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: druntime
        AssignedTo: nobody at puremagic.com
        ReportedBy: monarchdodra at gmail.com


--- Comment #0 from monarchdodra at gmail.com 2013-07-09 13:56:40 PDT ---
As the title explains, after a certain size (2048 for my 32 bit install on an
64 linux), the appendable data cannot be exploited anymore:

//--------
import std.stdio;
import core.memory;

void main()
{
    for ( size_t i = 4 ; i < 1_000_000 ; i *= 1.4 )
    {
        ubyte[] s;
        s.reserve(i);
        writefln("%6s: s.capacity  is %6s", i, s.capacity);
        assert(s.capacity >= i);
        auto p = s.ptr;
        auto s2 = p[0 .. 0];
        writefln("%6s: s2.capacity is %6s", i, s2.capacity);
        assert(s2.capacity >= i);
    }
    for ( size_t i = 4 ; i < 1_000_000 ; i *= 1.4 )
    {
        ubyte*  p = cast(ubyte*)GC.malloc(i, GC.BlkAttr.APPENDABLE);
        ubyte[] s = p[0 .. 0];
        writefln("%6s: s.capacity  is %6s", i, s.capacity);
        assert(s.capacity + 4 >= i); //This ends up failing.
    }
}
//--------
439521: s.capacity  is 442351
439521: s2.capacity is 442351
615329: s.capacity  is 618479
615329: s2.capacity is 618479
861460: s.capacity  is 864239
861460: s2.capacity is 864239
     4: p.capacity  is     15
     5: p.capacity  is     15
     6: p.capacity  is     15
     8: p.capacity  is     15
...
  1443: p.capacity  is   2046
  2020: p.capacity  is   2046
  2827: p.capacity  is      0
core.exception.AssertError at main(24): Assertion failure
//--------

I find this strange, because the first test shows that the allocation size
should not be a barrier.

Is the APPENDABLE data miss-placed or something? I can't really make sense of
why there would be a different behaviour between "s2" or "p" ... ?

This is problematic, as "malloc(APPENDABLE)" is the only way to allocate a
"true" d slice manually. Without this, functions such as array or appender,
will return arrays that will relocate after the very first append :(

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------