[TCLCORE] Re: Hintermayer's string allocation patch

[Jim I. <ji...@ap...>]

Eric,

On Wednesday, August 30, 2000, at 06:21 PM, Eric Melski wrote:

>  
> On Wed, 30 Aug 2000, Jim Ingham wrote: 
>  
> > As a test, try this little program: 
> >  
> > int 
> > main (int argc, char **argv) 
> > { 
> >   int bigsize = 0x5fffffff; 
> >   char * foo = (char *) malloc(bigsize); 
> >   if (!foo) { 
> >     printf("Oops, could not allocate %d bytes\n", bigsize); 
> >     return 1; 
> >   } else { 
> >     printf("I allocated %ud bytes\n", bigsize); 
> >   } 
> >  
> >   foo[500] = 'c'; 
> >   foo[0xffffff] = 'd'; 
> >   while (1) ; 
> >   return 0; 
> > } 
>  
> Again,  on Linux and Solaris, malloc returns 0 when the size requested 
> exceeds the available memory (physical memory + swap space).  When I 
> compile and run your program on Solaris I get: 
>  
> Oops, could not allocate 1610612735 bytes 
>  
> And on Linux: 
>  
> Oops, could not allocate 1610612735 bytes 
>  

Well, I am a bit happy about this.  Gdb (and thus yours truely) suffers a lot from having to cope with all the complexities of Mach + BSD, it is good to know that it really is good at some things :-)  Actually, the memory subsystem is pretty cool, you can do all sorts of wild things like allocate memory in another process's address space (provided you have the appropriate permissions) stuff junk there, and then tell the other process about it...  And since it can both deal with sparse memory regions, and dynamic swap sizes, it is good at handling process that need a lot of address space and/or memory.

>  
>  
> The performance penalty for using the new algorithm seems to be fairly 
> minimal, as the numbers that I posted earlier showed.  In addition, we can 
> tune TCL_GROWTH_LARGE_STRING up to a larger value if necessary, retaining  
> the original doubling algorithm for a longer period but still allowing 
> for growth of very large string.  I'm not dead set on using one megabyte 
> for that threshhold.  Perhaps 2 MB or 8 MB or 10 MB would be better. 
>  

Yeah, seems like you are getting into pathological cases anyway, even on Windows, so stepping the size up so you only hit the limit in pathological cases is probably not a bad idea.

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.