digitalmars.D - GC.calloc

David (6/6) Jul 17 2013 Why doesn't GC.calloc follow the function signature of stdc.calloc?

deadalnix (3/12) Jul 17 2013 We wont think anything if you don't give us something to think

David (10/22) Jul 17 2013 Well the obvious reason is, it will have the same api as the stdc.calloc

H. S. Teoh (7/33) Jul 17 2013 C does not have a native GC. I think expecting GC.calloc to be the same

David (1/7) Jul 17 2013 Why not, it's exactly named like calloc, same with malloc, qalloc and fr...

H. S. Teoh (8/17) Jul 17 2013 [...]

David (2/21) Jul 18 2013 Exactly if something is named like the C function it should behave like ...

Sean Kelly (5/13) Jul 17 2013 I sent a proposal to the runtime list ages ago about revamping the GC =

bearophile (5/9) Jul 17 2013 I think both are needed. The GC calloc is probably handy in some

Andrei Alexandrescu (4/9) Jul 17 2013 I don't find it all that useful as it's really an allocation followed by...

David (7/22) Jul 18 2013 I use it all the time, e.g. I have an array of blocks (65536*12Byte) and

Vladimir Panteleev (7/18) Jul 18 2013 calloc may still be useful as a stand-alone function. The

Marco Leise (13/32) Jul 19 2013 The calloc implemented in Linux only works like the GC.calloc

Daniel Murphy (4/10) Jul 18 2013 YES. This is the memory corruption bug that I've been stuck on for the ...

David (3/19) Jul 18 2013 Haha, glad I could help you! Looks like I am not the only one with this

Daniel Murphy (15/36) Jul 18 2013 Then I found this:

Rainer Schuetze (5/42) Jul 20 2013 This is a bad interaction of realloc and sizeOf. A related bug:

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

"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

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

"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

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

"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

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
 

Exactly if something is named like the C function it should behave like it.

Jul 18 2013

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

"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

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

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

"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

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

"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

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

"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

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

D Programming

C/C++ Programming

Other

digitalmars.D - GC.calloc