Re: Bug in GNAT? - Max_size_in_storage_elements insufficient

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 19/10/2016 03:39, Luke A. Guest wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>>> Well, then it's at least a bug in [Barnes] because there's an example
>>> like the above ones just with a simpler type. But I still think the idea
>>> here is/was to provide enough space for N items of some type.
>>
>> I am not sure if that were technically possible. Considering an
>> implementation of, for example, a marked-margins pool, the penalty to
>> have a guarantee would be extremely high.
>
> Surely that's what a static language can supply, the actual amount of space
> required?

In the mentioned above method you allocate a "margin" in front and in 
the end of each block. The margin contains an indicator if the block is 
free and the block size. When a block is freed the margins of adjacent 
blocks are inspected and the block is merged with its free neighbors. 
The memory overhead depends on the number of blocks, which in turn 
depends on the number of allocated objects and on how their blocks are 
distributed. In the worst case scenario you have a gap between each two 
allocated blocks. Which gives 2 * (2*N - 1) - 2 margins to keep in the pool.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de