www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - malloc in core.memory.GC

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 08 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 08 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 08 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 08 Apr 2012 16:33:01 -0400, Alex R=C3=B8nne 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 d=
o  =

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
Apr 09 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 09-04-2012 16:16, Steven Schveighoffer wrote:

 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.


Something that I've always disliked about the current GC.

In MCI, I can't provide finalization support when programs running in 
the VM use the D GC, because that *requires* me to use the Object layout 
for runtime objects. That's just not nice, since it adds (IIRC) 3 words 
of data that's basically useless to *me*. It would be nice if the GC 
supported finalization callbacks similar to how Boehm does it.


 -Steve



-- 
- Alex
Apr 09 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 09 Apr 2012 13:39:10 -0400, Alex R=C3=B8nne Petersen  =

<xtzgzorex gmail.com> wrote:


 In MCI, I can't provide finalization support when programs running in =


 =


 the VM use the D GC, because that *requires* me to use the Object layo=


ut  =


 for runtime objects. That's just not nice, since it adds (IIRC) 3 word=


s  =


 of data that's basically useless to *me*. It would be nice if the GC  =



 supported finalization callbacks similar to how Boehm does it.


Well, considering that there is no reason whatsoever to expect anything =
 =

stored in the block except the exact object it was created with, I see n=
o  =

reason why you couldn't store a TypeInfo reference in the block somewher=
e  =

(not part of the object/struct).

This would mean you could determine the type without having the type  =

system, and it would mean you would not carry around the extra baggage f=
or  =

calling the finalizer from the GC, when the struct is stored on the stac=
k.

I had great success with this when fixing array appending, I don't see w=
hy  =

it couldn't be done with finalization.  We do need compiler support to  =

make sure the struct dtor function pointer gets stored in the TypeInfo, =
 =

not sure if this has already been done.

-Steve
Apr 09 2012
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
ba is a BlockAttr bit field.=20

On Apr 8, 2012, at 1:05 PM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.o=
rg> wrote:


 At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
=20
 static void* malloc(size_t sz, uint ba =3D 0);
=20
 I assume each type has a specific ba. Is there a primitive in core.memory t=


o retrieve it?

=20
=20
 Thanks,
=20
 Andrei
Apr 08 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 08 2012
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Apr 8, 2012, at 3:42 PM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.o=
rg> wrote:


 On 4/8/12 5:33 PM, Sean Kelly wrote:

 ba is a BlockAttr bit field.


=20
 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 fi=
eld in TypeInfo that has the bitfield. And one of the flags in TypeInfo is b=
ackwards of what you'd expect. Really, I'd like to see all TypeInfo generate=
d by template code in druntime.=20=
Apr 08 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Apr 08 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 08 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 08 2012