www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC.calloc

reply David <d dav1d.de> writes:
Why doesn't GC.calloc follow the function signature of stdc.calloc?

calloc(num, size_per_element)

I think this should be changed, if no reason speaks against it, I can
look into changing this.
Of course this will break backwards compatability, but I think this is
worth it?
Jul 17 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 July 2013 at 18:00:03 UTC, David wrote:
 Why doesn't GC.calloc follow the function signature of 
 stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, 
 I can
 look into changing this.
 Of course this will break backwards compatability, but I think 
 this is
 worth it?

We wont think anything if you don't give us something to think about. You may start by explaining why you think it is better.
Jul 17 2013
parent reply David <d dav1d.de> writes:
Am 17.07.2013 20:17, schrieb deadalnix:
 On Wednesday, 17 July 2013 at 18:00:03 UTC, David wrote:
 Why doesn't GC.calloc follow the function signature of stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

We wont think anything if you don't give us something to think about. You may start by explaining why you think it is better.

Well the obvious reason is, it will have the same api as the stdc.calloc GC.calloc(num, Data.sizeof) will not do what stdc.calloc(num, Data.sizeof) does If you naivly assume they do the same (because that compiles), you will end up getting rather strange segmentation faults. D tries to be C compatible a lot, I heared it also in someones talk recently, that this is indeed a goal, something that works in C and D has to do the same, in this case GC.calloc does something entirely different.
Jul 17 2013
parent reply David <d dav1d.de> writes:
 C does not have a native GC. I think expecting GC.calloc to be the same
 as stdc.calloc is fallacious. But I agree that perhaps "calloc" isn't a
 good name for the GC method.
 
 
 T

Why not, it's exactly named like calloc, same with malloc, qalloc and free?
Jul 17 2013
parent David <d dav1d.de> writes:
Am 18.07.2013 00:42, schrieb H. S. Teoh:
 On Thu, Jul 18, 2013 at 12:38:37AM +0200, David wrote:
 C does not have a native GC. I think expecting GC.calloc to be the
 same as stdc.calloc is fallacious. But I agree that perhaps "calloc"
 isn't a good name for the GC method.


 T

Why not, it's exactly named like calloc, same with malloc, qalloc and free?

Naming it as "calloc" gives the false impression that perhaps it's equivalent to C's calloc, which is not true. Which is probably why you're complaining about the different order of parameters. :) T

Jul 18 2013
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Jul 17, 2013, at 11:00 AM, David <d dav1d.de> wrote:

 Why doesn't GC.calloc follow the function signature of stdc.calloc?
=20
 calloc(num, size_per_element)
=20
 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

I sent a proposal to the runtime list ages ago about revamping the GC = API. But really, I'd like to eliminate GC.calloc entirely. I'd rather = have an allocation routine that takes a TypeInfo and uses that to = initialize the block rather than just doing a memset(0) as per calloc.=
Jul 17 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/13 1:33 PM, bearophile wrote:
 Sean Kelly:

 I'd like to eliminate GC.calloc entirely. I'd rather have an
 allocation routine that takes a TypeInfo and uses that to initialize
 the block rather than just doing a memset(0) as per calloc.

I think both are needed. The GC calloc is probably handy in some cases.

I don't find it all that useful as it's really an allocation followed by a fill. Andrei
Jul 17 2013
parent David <d dav1d.de> writes:
Am 18.07.2013 02:21, schrieb Andrei Alexandrescu:
 On 7/17/13 1:33 PM, bearophile wrote:
 Sean Kelly:

 I'd like to eliminate GC.calloc entirely. I'd rather have an
 allocation routine that takes a TypeInfo and uses that to initialize
 the block rather than just doing a memset(0) as per calloc.

I think both are needed. The GC calloc is probably handy in some cases.

I don't find it all that useful as it's really an allocation followed by a fill. Andrei

I use it all the time, e.g. I have an array of blocks (65536*12Byte) and I don't want the GC to care about this chunk of data (since it exists up to 961 times) but I can't just have it filled with random data -> calloc. Often when I was relativly new to C I always called malloc followed by a memset to 0, until I learned about calloc (but that's getting offtopic).
Jul 18 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Sean Kelly:

 I'd like to eliminate GC.calloc entirely.  I'd rather have an 
 allocation routine that takes a TypeInfo and uses that to 
 initialize the block rather than just doing a memset(0) as per 
 calloc.

I think both are needed. The GC calloc is probably handy in some cases. Bye, bearophile
Jul 17 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 17, 2013 at 11:46:57PM +0200, David wrote:
 Am 17.07.2013 20:17, schrieb deadalnix:
 On Wednesday, 17 July 2013 at 18:00:03 UTC, David wrote:
 Why doesn't GC.calloc follow the function signature of stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

We wont think anything if you don't give us something to think about. You may start by explaining why you think it is better.

Well the obvious reason is, it will have the same api as the stdc.calloc GC.calloc(num, Data.sizeof) will not do what stdc.calloc(num, Data.sizeof) does If you naivly assume they do the same (because that compiles), you will end up getting rather strange segmentation faults. D tries to be C compatible a lot, I heared it also in someones talk recently, that this is indeed a goal, something that works in C and D has to do the same, in this case GC.calloc does something entirely different.

C does not have a native GC. I think expecting GC.calloc to be the same as stdc.calloc is fallacious. But I agree that perhaps "calloc" isn't a good name for the GC method. T -- In a world without fences, who needs Windows and Gates? -- Christian Surchi
Jul 17 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 18, 2013 at 12:38:37AM +0200, David wrote:
 C does not have a native GC. I think expecting GC.calloc to be the
 same as stdc.calloc is fallacious. But I agree that perhaps "calloc"
 isn't a good name for the GC method.
 
 
 T

Why not, it's exactly named like calloc, same with malloc, qalloc and free?

Naming it as "calloc" gives the false impression that perhaps it's equivalent to C's calloc, which is not true. Which is probably why you're complaining about the different order of parameters. :) T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
Jul 17 2013
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 18 July 2013 at 09:55:15 UTC, David wrote:
 I use it all the time, e.g. I have an array of blocks 
 (65536*12Byte) and
 I don't want the GC to care about this chunk of data (since it 
 exists up
 to 961 times) but I can't just have it filled with random data 
 ->
 calloc. Often when I was relativly new to C I always called 
 malloc
 followed by a memset to 0, until I learned about calloc (but 
 that's
 getting offtopic).

calloc may still be useful as a stand-alone function. The question is whether it makes sense to be part of the GC interface, which all GCs need to implement. I think it only makes sense if some GC implementations have knowledge that allows them to return 0-filled memory without actually filling it all (e.g. if it is known that the OS does it for them).
Jul 18 2013
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"David" <d dav1d.de> wrote in message news:ks6m33$o9b$1 digitalmars.com...
 Why doesn't GC.calloc follow the function signature of stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

YES. This is the memory corruption bug that I've been stuck on for the last week in the DDMD port. Thankyou so much for bringing this up, otherwise I'd still be stuck.
Jul 18 2013
parent reply David <d dav1d.de> writes:
Am 18.07.2013 13:49, schrieb Daniel Murphy:
 "David" <d dav1d.de> wrote in message news:ks6m33$o9b$1 digitalmars.com...
 Why doesn't GC.calloc follow the function signature of stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

YES. This is the memory corruption bug that I've been stuck on for the last week in the DDMD port. Thankyou so much for bringing this up, otherwise I'd still be stuck.

Haha, glad I could help you! Looks like I am not the only one with this problem.
Jul 18 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"David" <d dav1d.de> wrote in message news:ks8lcs$184p$1 digitalmars.com...
 Am 18.07.2013 13:49, schrieb Daniel Murphy:
 "David" <d dav1d.de> wrote in message 
 news:ks6m33$o9b$1 digitalmars.com...
 Why doesn't GC.calloc follow the function signature of stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

YES. This is the memory corruption bug that I've been stuck on for the last week in the DDMD port. Thankyou so much for bringing this up, otherwise I'd still be stuck.

Haha, glad I could help you! Looks like I am not the only one with this problem.

Then I found this: import core.memory; extern(C) int printf(const char *, ...); void main() { auto data = cast(int*)GC.realloc(null, 1024 * 4); printf("was %d\n", GC.sizeOf(data)); data = cast(int*)GC.realloc(data, 1025 * 4); printf("is %d\n", GC.sizeOf(data)); } prints: was 4096 is 4096 Now I'm really worried.
Jul 18 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.07.2013 16:09, Daniel Murphy wrote:
 "David" <d dav1d.de> wrote in message news:ks8lcs$184p$1 digitalmars.com...
 Am 18.07.2013 13:49, schrieb Daniel Murphy:
 "David" <d dav1d.de> wrote in message
 news:ks6m33$o9b$1 digitalmars.com...
 Why doesn't GC.calloc follow the function signature of stdc.calloc?

 calloc(num, size_per_element)

 I think this should be changed, if no reason speaks against it, I can
 look into changing this.
 Of course this will break backwards compatability, but I think this is
 worth it?

YES. This is the memory corruption bug that I've been stuck on for the last week in the DDMD port. Thankyou so much for bringing this up, otherwise I'd still be stuck.

Haha, glad I could help you! Looks like I am not the only one with this problem.

Then I found this: import core.memory; extern(C) int printf(const char *, ...); void main() { auto data = cast(int*)GC.realloc(null, 1024 * 4); printf("was %d\n", GC.sizeOf(data)); data = cast(int*)GC.realloc(data, 1025 * 4); printf("is %d\n", GC.sizeOf(data)); } prints: was 4096 is 4096 Now I'm really worried.

This is a bad interaction of realloc and sizeOf. A related bug: http://d.puremagic.com/issues/show_bug.cgi?id=6372 and here is a pull request: https://github.com/D-Programming-Language/druntime/pull/547
Jul 20 2013
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 18 Jul 2013 13:00:24 +0200
schrieb "Vladimir Panteleev" <vladimir thecybershadow.net>:

 On Thursday, 18 July 2013 at 09:55:15 UTC, David wrote:
 I use it all the time, e.g. I have an array of blocks 
 (65536*12Byte) and
 I don't want the GC to care about this chunk of data (since it 
 exists up
 to 961 times) but I can't just have it filled with random data 
 ->
 calloc. Often when I was relativly new to C I always called 
 malloc
 followed by a memset to 0, until I learned about calloc (but 
 that's
 getting offtopic).

calloc may still be useful as a stand-alone function. The question is whether it makes sense to be part of the GC interface, which all GCs need to implement. I think it only makes sense if some GC implementations have knowledge that allows them to return 0-filled memory without actually filling it all (e.g. if it is known that the OS does it for them).

The calloc implemented in Linux only works like the GC.calloc up to ~24 MiB or so. After that it does neither set anything to zero nor does it allocate physical memory. It just gives you X references to a read-only page filled with zeroes, that is marked copy-on-write. Thus with C calloc you can allocate gigabytes of "zero initialized" memory in an instant. But the real benefit with the C calloc > ~24 MiB is that the memory pages don't consume RAM until you write to them. -- Marco
Jul 19 2013