[Issue 10589] 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



--- Comment #2 from monarchdodra at gmail.com 2013-07-12 14:29:45 PDT ---
(In reply to comment #1)
> I think you are mixing two levels of abstractions here:
> 
>         ubyte*  p = cast(ubyte*)GC.malloc(i, GC.BlkAttr.APPENDABLE);
>         ubyte[] s = p[0 .. 0];
>         writefln("%6s: s.capacity  is %6s", i, s.capacity);
> 
> GC.malloc requests raw memory from the GC. capacity is a function very specific
> to the way arrays are implemented on top of it in rt/lifetime.d. It assumes
> that any allocation with bit APPENDABLE set and that is larger than a page of
> 4kB reserves 16 bytes at the start of the allocation to store the actually used
> length of the memory.
> So, to create an empty array manually that works with capacity, you'd have to
> set s to
> 
>    auto start = i <= 2048 ? 0 : 16;
>    ubyte[] s = p[start .. start];

Hum. That worked.

Is the memory layout for the APPENDABLE data documented somewhere, or are these
just reverse-engineered magic numbers?

> and you'd better clean that full memory block first to avoid the length field
> containing garbage.

Nope (I think). Length is carried in the slice, not the block. Block only
contains capacity/used info.

------------------------------------------------------------------------

Thank you for your answer.

I suppose the behavior isn't going to change. Still, this requires more
support. I think APPENDABLE should be better documented.

In particular, the magic numbers should be user accessible via manifest
constants, or functions, so as to not have to guess/reverse engineer them. This
is what I've discovered:

   0 -  256 bytes:
       1 Byte APPENDABLE info at end;
         Capacity = memory size -  1;
 257 - 2048 bytes:
       2 Byte APPENDABLE info at end;
         Capacity = memory size -  2;
2049 - **** bytes:
      16 Byte APPENDABLE info at beginning;
       1 Byte unknown info at end;
         Capacity = memory size - 17;

Are these numbers platform depending? What the heck is that 1 byte that leads
to 17 byte difference I'm seeing.

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