[ODE] Allocation problem?

[Jon Watte (ODE)]

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.

Cheers,

			/ h+


Geoff Carlton wrote:
> Hi,
> 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.
> 
> Cheers,
> Geoff
> 
> Jon Watte (ODE) wrote:
>> Yes, dWorldQuickStep() still uses the stack, although less of it than 
>> dWorldStep() (last I checked -- many moons ago).
>>
>> Cheers,
>>
>>             / 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
>>>> dWorldQuickStep().
>>>>       
>>> 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.
>>>
>>> Jason
>>>
>>>
>>>     
>> _______________________________________________
>> ODE mailing list
>> ODE at q12.org
>> http://q12.org/mailman/listinfo/ode
>>
>>
>>   
> 
>