Re: error in strings.c ?

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-11 09:58:18

Toon Knapen <toon.knapen_at_[hidden]> writes:

> 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. 

Yes, and it should be clear from the code that it holds. At least,
it was for me.

> Adding 'assert( self->size == self->capacity )' I
> get an assertion failure during the bootstrapping though.

Oh? Can you give any more info? What's the stack look like?

> 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? 

Not at all; it's a good idea.

> Of course I will always request approval of a patch on the ml before
> committing.

Go ahead and commit, but do post a notice. I'll clean up any mistakes.

>>>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)

Perforce Jam used lots of fixed-sized buffers that would occasionally
overrun, which is why I added this string "class". The opt
buffer was designed to keep most of Perforce's performance while
adding correctness.

> 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? 

Not me, but I'm pretty sure Volodya did.

> 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.

I don't know. If there's a bug in string it should be fairly
self-evident.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com