View mode: basic / threaded / horizontal-split · Log in · Help
April 08, 2012
malloc in core.memory.GC
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
April 08, 2012
Re: malloc in core.memory.GC
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
April 08, 2012
Re: malloc in core.memory.GC
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
April 08, 2012
Re: malloc in core.memory.GC
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
April 08, 2012
Re: malloc in core.memory.GC
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
April 08, 2012
Re: malloc in core.memory.GC
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
April 08, 2012
Re: malloc in core.memory.GC
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
April 09, 2012
Re: malloc in core.memory.GC
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.
April 09, 2012
Re: malloc in core.memory.GC
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.
April 09, 2012
Re: malloc in core.memory.GC
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home