[TCLCORE] Re: Hintermayer's string allocation patch

[Brent W. <we...@aj...>]

>>>Jim Ingham said:
 > 
 > On Wednesday, August 30, 2000, at 04:49 PM, Jeffrey Hobbs wrote:
 > 
 > > Yes and no.  Sure, the memory is just reserved, but the mem allocator 
 > > will still bomb if you ask for more space than it could promise.  The 
 > > point of the mem efficiency part is that we don't get too greedy about 
 > > needing so much more space than we need.  That way we can push the 
 > > boundaries of how much mem we will actually be able to use without 
 > > the mem allocator crapping out because we're overly greedy. 
 > >  
 > 
 > Yes, but the point of the last note was that what "more" is is pretty huge.  For instance, I th
     ink in general the allocator doesn't check whether a given allocation fits in the available s
     wap space but rather fills it as you actually write out pages to swap.  This is the right thi
     ng to do, since that way you can for instance allocate a large matrix, and if you only fill i
     t sparsely, you aren't limited by the size of the matrix, only by the pages you use.  MacOS X
     , does it this way, at least.  I imagine other Unixes work in much the same way...

Apparently MacOS is more advanced than UNIX in this area.  In UNIX you have
to be able to allocate the swap space to cover the virtual memory.  So, in practice,
if you have 300 Meg of swap space, 192 Meg of real memory, and a 160 Meg string,
you cannot append one byte to it in Tcl.

I also note that using realloc accounts for essentially all the performance speedup.
Changing the doubling behaviour after a certain limit makes
good sense, and it looks like using realloc may allow the system to optimize
the reallocation by doing VM page remapping and avoiding the big copy that John O
is worrying about.

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com

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