Boost logo

Boost-Build :

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

Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at