5 ms·

If you're getting memory from the OS it's going to be initializing it for you, so no speedup. Otherwise you get memory as it was left by some other process, po

by cbr 15y ago

If you're getting memory from the OS it's going to be initializing it for you, so no speedup. Otherwise you get memory as it was left by some other process, potentially leaking passwords or other sensitive information

lloeki 15y ago
Interestingly enough malloc(3) on Lucid Lynx box says: malloc() allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared. whereas Lion says nothing particular about it So I wrote a quickie: #include <stdlib.h> #include <stdio.h> int main() { int m = 1024*1024; //1M int t = 1024*m; //total count: here 1G char *v = calloc(1, t*sizeof(char)); //total size: 1GB for(int i=0; i<t; i++) { if (v[i] != 0) { printf("%016u @%x %x\n", i, v+i, v[i]); } else if (i % (t/10) == 0) { printf("%016u @%x\n", i ,v+i); } } } Ran multiple times with various sizes including big enough sizes (t) to statistically cover a good deal of physical RAM, and the trigger never triggers. I notice though that on Mac OS X the program starts right on the spot, while there is always a constant delay on Lucid. Looks like one zeroes on demand (by chunks probably) whereas the other zeroes initially.
- petsos 15y ago
  calloc differs from malloc, as it clears the memory. From the Mac OS X man page: The calloc() function contiguously allocates enough space for count objects that are size bytes of memory each and returns a pointer to the allocated memory. The allocated memory is filled with bytes of value zero.
  - lloeki 15y ago
    Ah sorry, bad version copy/paste on my part. I actually used calloc at some point to compare behaviors in allocation time with malloc, but with malloc it still has zeros everywhere. Nice for security, but how would one proceed when really wanting pedal-to-the-metal performance?
fooyc 15y ago
When you free() a memory region, it's not returned to the OS. It's only made available for later mallocs. When malloc returns memory previously freed by the process, it effectively returns uninitialized memory, without leaking any information that's not already known to the calling process.
- aidenn0 15y ago
  This depends on the implementation. There are implementations that always unmamp freed memory to catch use after free errors (I think there is a BSD that uses this by default)

by cbr 15y ago

lloeki 15y ago

Interestingly enough malloc(3) on Lucid Lynx box says: malloc() allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared. whereas Lion says nothing particular about it So I wrote a quickie: #include <stdlib.h> #include <stdio.h> int main() { int m = 1024*1024; //1M int t = 1024*m; //total count: here 1G char *v = calloc(1, t*sizeof(char)); //total size: 1GB for(int i=0; i<t; i++) { if (v[i] != 0) { printf("%016u @%x %x\n", i, v+i, v[i]); } else if (i % (t/10) == 0) { printf("%016u @%x\n", i ,v+i); } } } Ran multiple times with various sizes including big enough sizes (t) to statistically cover a good deal of physical RAM, and the trigger never triggers. I notice though that on Mac OS X the program starts right on the spot, while there is always a constant delay on Lucid. Looks like one zeroes on demand (by chunks probably) whereas the other zeroes initially.

petsos 15y ago
calloc differs from malloc, as it clears the memory. From the Mac OS X man page: The calloc() function contiguously allocates enough space for count objects that are size bytes of memory each and returns a pointer to the allocated memory. The allocated memory is filled with bytes of value zero.
- lloeki 15y ago
  Ah sorry, bad version copy/paste on my part. I actually used calloc at some point to compare behaviors in allocation time with malloc, but with malloc it still has zeros everywhere. Nice for security, but how would one proceed when really wanting pedal-to-the-metal performance?

fooyc 15y ago

When you free() a memory region, it's not returned to the OS. It's only made available for later mallocs. When malloc returns memory previously freed by the process, it effectively returns uninitialized memory, without leaking any information that's not already known to the calling process.

aidenn0 15y ago
This depends on the implementation. There are implementations that always unmamp freed memory to catch use after free errors (I think there is a BSD that uses this by default)