[ODE] Allocation problem?
Jon Watte (ODE)
hplus-ode at mindcontrol.org
Wed Jun 7 09:28:03 MST 2006
This already got implemented once AFAICR. There was a big discussion WRT
the overhead of malloc() vs the overhead of a linear allocator vs
whether there should be one big block or on-demand allocated small
blocks, vs static block re-use, ...
Thinking about it: did that ever actually make it into the codebase? If
it did, then the dALLOC failing could be because of some heap
corruption, instead of running out of stack.
Geoff Carlton wrote:
> I've often wondered whether a different allocator strategy might be more
> reliable. Here is one strategy I've seen before:
> - Allocate out of blocks of a fixed size (e.g. 1MB). When a block is
> full, malloc a new block, linked together in an "active" list.
> - Free is no-op.
> - When the operation (WorldStep) is finished, move all blocks into a
> free list ready to start again.
> - Blocks are only deleted at shutdown.
> Essentially, its used for this sort of thing where memory is used as
> part of an operation, then completely freed. It grows to a whatever
> size is needed, and in subsequent operations just references existing
> memory blocks. It is still relatively fast, and can grow to an
> arbitrary size without the danger of stack overflow.
> Thinking about it, the main disadvantage seems to be memory
> fragmentation, because allocs hop over to different 1MB blocks in
> memory. Could be solved with a memory consolidation step, where it
> totals the size used at the end of the operation and then replaces all
> the blocks with one of the new total size. I've never heard of this
> idea before, but it seems like it might work, albeit at increased cost
> as the simulation size is growing.
> Actually, could we calculate the maximum size needed based on the number
> of bodies? Could be a third alternative, keep a buffer around of the
> max theoretical size, resizing it larger at the start of each step if
> needed. Keeps everything in one contiguous array.
> Not that I've had any problems with alloca, but it does seem a little
> unreliable if running big simulations.
> Jon Watte (ODE) wrote:
>> Yes, dWorldQuickStep() still uses the stack, although less of it than
>> dWorldStep() (last I checked -- many moons ago).
>> / h+
>> Jason Perkins wrote:
>>> On 6/6/06, Jon Watte (ODE) <hplus-ode at mindcontrol.org> wrote:
>>>> My guess is you're on Windows, and using plain dWorldStep(). In that
>>>> case, you're running out of stack. This issue is mentioned more
>>>> thoroughly in the ODE documentation. Simple solution: switch to
>>> I'm curious about this...test_crash uses dWorldQuickStep() and it
>>> still crashes at that same location. So does dWorldQuickStep() also
>>> have a stack space requirement? Just trying to get my head around it.
>> ODE mailing list
>> ODE at q12.org
More information about the ODE