Re: [jamboost] Re: error in strings.c ?

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2004-08-11 09:35:40

David Abrahams wrote:

> You're missing the fact that extend_full is only called when size ==
> capacity.

Do you mean that self->size == self->capacity is a precondition for
calling extend_full. Adding 'assert( self->size == self->capacity )' I
get an assertion failure during the bootstrapping though.

To avoid misintrepretation of what the different functions do (for
myself but also for people that will be looking at the bjam sources in
the future), would you mind if I add documentation to the function
declarations describing the functionality, pre- and post-conditions? Of
course I will always request approval of a patch on the ml before
committing.

>>Can't we rely on small-object-allocation optimisation of malloc as many 
>>compilers do now for the new operator?
> 
> 
> I doubt it. There are lots of bad mallocs out there and many std
> libraries still implement the small string optimization. But do the
> benchmarks yourself if you want to know.
> 

I checked the waste (of not using opt but instead mallocing) and the
total amount of memory consumed by all non-used opt's is very small 
(actually during most of the build process at most 2 strings longer than 
32chars were allocated. This surprised me. Or my instrumentation of the 
code was wrong (which counted the number of strings in memory) or bjam 
is constantly creating and deleting strings)

OTOH I have done timings for malloc with gcc/linux, icc/linux and
visualage/aix. Seems like gcc and icc both implement 
small-object-allocation-optimisation up to objects of 64bytes whereas 
VisualAge does not.

> I think you're looking in the wrong place.

Possibly. This is the first time I really dived into the bjam source 
code. But have you run valgrind on bjam? If so, did you got warnings 
from valgrind or not? Because I wonder if I have done soth wrong that 
made that my bjam seg faulted.