[ODE] Segfaulting ODE with too many objects -- ALLOC vs MALLOC

[Kyle Hubert]

On 9/30/06, Jon Watte (ODE) <hplus-ode at mindcontrol.org> wrote:
>
>
> Kyle Hubert wrote:
> > One more thing, if you look in release 0.7 on line 409 in
> > ode/src/quickstep.cpp, you'll see an unprotected alloca. In fact, I
> > count two unprotected allocas in collision_space.cpp and six
> > unprotected allocas in quickstep.cpp. That's only my quick poking. I
> > smell a code review.
> >
>
> As I said before:
>
> With the proper implementation of alloca on top of malloc(), you don't
> need to protect the alloca calls with free calls.

??? Alloca never needs to call free in the glibc sense. However, in
such a case that someone would be developing on a platform that
doesn't have glibc, say a platform that only implements Open Groups
system interfactes guide V3, then they don't have access to the alloca
function. As such they would go about implementing the ALLOCA macro
for the C-preprocessor. If a group does this they will run into at
least 6 undefined symbols as I pointed out, since those calls are
unprotected by the macro definition. Of course, if their symbol was
alloca it would all work under the covers at link time.

> Insert a call to something like "init_alloca" at the beginning of the
> solver, and have this call clear out all the previous frames alloca()-ed
> memory.
> Then start over.

Sure. That's one implementation.

> Implement alloca() by allocating a large chunk of memory (1 MB?), and
> moving an allocation pointer through this chunk. If you overrun the end,
> allocate a second chunk, and link it to the first, and start allocating
> from there instead. You might not want to ever free these chunks; just
> re-use them for future frames. This way, the malloc() contention cost is
> only hit the first frame, and it's otherwise almost as fast as alloca()
> (one additional cache line needed). The draw-back is that it's not
> thread safe, unless you use TLS (which costs another cache line).

That's another one. I think we are in agreement that there are ways to
reduce the cost malloc via one out of every thousand added objects, or
thereabouts. There are even ways, as you point out, to reduce the cost
of a memcpy in realloc.

> The currently proposed patch is not as optimal as what I describe above,
> if I remember correctly.

I noticed... ;) I'm working on a new one. What's the process around
here for a review/checkin? I'll even throw in a benchmarker for free.

-Kyle