site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com The program is listed belowl, to compile it just execute: gcc -arch ppc64 c-bigmem-test.c -o c-bigmem-test.exe "c-bigmem-test.exe" is the output - an executable file you may run. That depends on your definition of "correct". Here is the code -------- #include <stdio.h> #include <string.h> #include <stdlib.h> #define ARRAY_SIZE 1000000 int main(){ char **bigbuf; char buf [ARRAY_SIZE]; long long int i=0; for(i=0;i<ARRAY_SIZE;i++){ buf[i]='A'; } bigbuf=malloc(ARRAY_SIZE*sizeof(char *)); if(bigbuf==NULL){ printf("Main malloc failed!\n"); } i=0; while(++i){ char * str_tmp=malloc(ARRAY_SIZE*sizeof(char)); if(str_tmp==NULL){ printf("Internal malloc failed!\n"); } bigbuf[i]=str_tmp; strcpy(bigbuf[i], buf); if(i%10==0) {printf("MB allocated: %lld\n",i);}; } return 0; } -------- This email sent to agentm@themactionfaction.com |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- AgentM agentm@themactionfaction.com |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Nov 3, 2005, at 1:30 PM, Bob Bader wrote: ---------------- Observations from my users ----------------------- 1. The "top" command does not display the correct memory allocation status for a given process. To be precise, it is not able to show the values for memory greater than 4GB so it's a kind of hard to test high-mem applications. Looks like it's just the old 32bit "top", without 64bit capability. Yes. Unfortunately, even the 64-bit app can't query how much memory it is using because the kernel structures involved don't support 64- bit-sized reporting. Oops! http://lists.apple.com/archives/darwin-kernel/2005/Sep/msg00055.html and the follow-up: http://lists.apple.com/archives/darwin-kernel/2005/Sep/msg00061.html 2. We wrote and executed a custom C program to test the 64bit C compiler the system came with. It also tests 64bit environment and a system's general ability to handle high-mem apps. The application was able to allocate about 15GB on your test box and ... then the machine rebooted! Unacceptable! The program is straightforward and it just tries to allocate more and more memory and it doesn't stop by itself (leave it or kill it!). On the screen you'll see the value of current memory taken. We tested it on the 64bit Linux /the memory status obtained from 64bit "top" matched the values printed out by our C program/ and when all system resources (physical memory + swap/hdd/ memory ) ran out, it was killed by the kernel which is correct. Linux (by default) employs the so-called Out-Of-Memory Killer (OOM Killer) which allows malloc to overcommit and effectively lie about how much memory is available for allocation. If the overcommitted pages are then written (as you do below) then a heuristic takes over in the kernel to kill (with SIGKILL) some program-- cross your fingers and hope it doesn't kill your database or long-running number- cruncher. More details and the way to shut this off at: http://lwn.net/Articles/104179/ Obviously, you revealed a bug in the Darwin kernel's 64-bit handling (and an easy-to-use DOS), but POSIX has a well-defined method of notifying the program that there is no more memory- namely returning NULL from malloc(). So please don't rely on the KILL behavior. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/agentm% 40themactionfaction.com This email sent to site_archiver@lists.apple.com