Re: Bug in GNAT? - Max_size_in_storage_elements insufficient

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

On 2016-10-18 17:26, Vratislav Podzimek wrote:
> On Tue, 18 Oct 2016 14:35:15 +0200, Dmitry A. Kazakov wrote:
>
>> On 18/10/2016 13:17, Vratislav Podzimek wrote:
>>
>>> Or am I missing something?
>>
>> A storage pool requires additional space to organize its structure and
>> maintain its state. Depending on the method it is usually impossible to
>> estimate the exact number of object  the pool may hold. It depends on
>> the individual sizes of the objects, the history of object's allocation
>> and deallocation, the history of claiming the memory for the parts of
>> the pool from the OS (a pool can be segmented).
>
> 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.

> That's what
> the 'Max_size_in_storage_elements' attribute should be good for. And
> there's no fragmentation nor history of allocation/deallocation in my
> case.

You don't know the implementation of. A segmented pool may request 
system memory on demand adapting the size of segments to the allocation 
requests: Max (Chunk size, Requested size).

> If I specify I want space for 4 records, I should get space for 4
> records. Not slightly less due to some hidden, unpredictable overhead.

If you know the pool size in advance and the objects in it, why don't 
you use a custom pool backed by an array? An arena pool would be exactly 
for this and trivial to implement in Ada.

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