At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is

static void* malloc(size_t sz, uint ba = 0);

I assume each type has a specific ba. Is there a primitive in core.memory to retrieve it?


Thanks,

Andrei

On 08-04-2012 22:05, Andrei Alexandrescu wrote:
> At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
>
> static void* malloc(size_t sz, uint ba = 0);
>
> I assume each type has a specific ba. Is there a primitive in
> core.memory to retrieve it?
>
>
> Thanks,
>
> Andrei

Currently, no. I think (but don't quote me on this) that there is some compiler magic involved. That, or it's hidden somewhere deep inside rt.* (probably rt.lifetime).

FWIW:

NO_SCAN is set for types that have no GC-relevant pointers (i.e. it's pure data; integers, floats, etc). We ought to document under what exact circumstances a type has this flag...

APPENDABLE is, IIRC, mostly an internal attribute used for the array append cache. You can ignore it entirely (we should document this).

NO_INTERIOR can probably be ignored for most practical purposes as it's an optional optimization. It won't be used unless you explicitly tell the GC to do so.

FINALIZE is only relevant if the type allocated in the block has a destructor (it simply specifies that finalization is then desired).

NO_MOVE isn't currently used for anything since the GC doesn't do any copying/compaction (in general). Even when the GC does get such semantics, this probably falls into the same ballpark as NO_INTERIOR (i.e. a library shouldn't mess with this).

You can test any of the above flags by creating types fulfilling the criterion and querying the GC for their memory block's attributes.

TL;DR: Only NO_SCAN and FINALIZE are interesting if this is for your allocators design.

-- 
- Alex

On 08-04-2012 22:33, Alex Rønne Petersen wrote:
> On 08-04-2012 22:05, Andrei Alexandrescu wrote:
>> At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
>>
>> static void* malloc(size_t sz, uint ba = 0);
>>
>> I assume each type has a specific ba. Is there a primitive in
>> core.memory to retrieve it?
>>
>>
>> Thanks,
>>
>> Andrei
>
> Currently, no. I think (but don't quote me on this) that there is some
> compiler magic involved. That, or it's hidden somewhere deep inside rt.*
> (probably rt.lifetime).
>
> FWIW:
>
> NO_SCAN is set for types that have no GC-relevant pointers (i.e. it's
> pure data; integers, floats, etc). We ought to document under what exact
> circumstances a type has this flag...
>
> APPENDABLE is, IIRC, mostly an internal attribute used for the array
> append cache. You can ignore it entirely (we should document this).
>
> NO_INTERIOR can probably be ignored for most practical purposes as it's
> an optional optimization. It won't be used unless you explicitly tell
> the GC to do so.
>
> FINALIZE is only relevant if the type allocated in the block has a
> destructor (it simply specifies that finalization is then desired).
>
> NO_MOVE isn't currently used for anything since the GC doesn't do any
> copying/compaction (in general). Even when the GC does get such
> semantics, this probably falls into the same ballpark as NO_INTERIOR
> (i.e. a library shouldn't mess with this).
>
> You can test any of the above flags by creating types fulfilling the
> criterion and querying the GC for their memory block's attributes.
>
> TL;DR: Only NO_SCAN and FINALIZE are interesting if this is for your
> allocators design.
>

I should add that both NO_INTERIOR and NO_MOVE should *not* be generally used at all by a library or similar. They require careful consideration and defensive programming by the programmer.

-- 
- Alex

ba is a BlockAttr bit field.

On Apr 8, 2012, at 1:05 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
> 
> static void* malloc(size_t sz, uint ba = 0);
> 
> I assume each type has a specific ba. Is there a primitive in core.memory to retrieve it?
> 
> 
> Thanks,
> 
> Andrei

On 08-04-2012 22:05, Andrei Alexandrescu wrote:
> At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
>
> static void* malloc(size_t sz, uint ba = 0);
>
> I assume each type has a specific ba. Is there a primitive in
> core.memory to retrieve it?
>
>
> Thanks,
>
> Andrei

Heh, even that is not actually obvious. We really need to fix the GC docs...

-- 
- Alex

On 09-04-2012 00:34, Alex Rønne Petersen wrote:
> On 08-04-2012 22:05, Andrei Alexandrescu wrote:
>> At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
>>
>> static void* malloc(size_t sz, uint ba = 0);
>>
>> I assume each type has a specific ba. Is there a primitive in
>> core.memory to retrieve it?
>>
>>
>> Thanks,
>>
>> Andrei
>
> Heh, even that is not actually obvious. We really need to fix the GC
> docs...
>

Err, that was meant to be a reply to Sean's post...

-- 
- Alex

On 4/8/12 5:33 PM, Sean Kelly wrote:
> ba is a BlockAttr bit field.

Yah. The question was how can I retrieve a type's "native" bit field, i.e. NO_SCAN for int, FINALIZE for class objects, etc.

Andrei

On Apr 8, 2012, at 3:42 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/8/12 5:33 PM, Sean Kelly wrote:
>> ba is a BlockAttr bit field.
> 
> Yah. The question was how can I retrieve a type's "native" bit field, i.e. NO_SCAN for int, FINALIZE for class objects, etc.

getAttr for allocated blocks, as I'm sure you know. But there's no single field in TypeInfo that has the bitfield. And one of the flags in TypeInfo is backwards of what you'd expect. Really, I'd like to see all TypeInfo generated by template code in druntime.

On Sun, Apr 08, 2012 at 10:48:53PM -0700, Sean Kelly wrote: [...]
> Really, I'd like to see all TypeInfo generated by template code in druntime.

Will that also solve the current weirdness with TypeInfo_Aya and TypeInfo_Aa being used for string and char[], respectively, but TypeInfo_Array being used for const(char)[]? (Which is the source of a bug with getHash being inconsistent between the former and the latter.)

If so, I'd say, definitely move TypeInfo to druntime. The more hacks we eliminate from the compiler, the cleaner and less buggy it will be.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

On Sun, 08 Apr 2012 16:33:01 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> APPENDABLE is, IIRC, mostly an internal attribute used for the array append cache. You can ignore it entirely (we should document this).

It's used to flag that the block of GC data is actually an appendable array.  If this flag is missing, and you attempt to append data that points at the block, it will always reallocate.  If this flag is present, it assumes it has a valid the "used" length in the block, and proceed.  Do NOT set this flag unless you know what you are doing.  Let the runtime do it.

> FINALIZE is only relevant if the type allocated in the block has a destructor (it simply specifies that finalization is then desired).

I'll add that it not only identifies the type stored has a dtor, the GC expects that the layout of the block is of type Object.  This is an important distinction, because it will use that information to traverse the vtable looking for dtors.  For example, just setting this flag for a struct that has a dtor will not work, because a struct has no vtable.

-Steve