* Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
2016-10-18 15:26 ` Vratislav Podzimek
@ 2016-10-18 16:03 ` Dmitry A. Kazakov
2016-10-19 1:39 ` Luke A. Guest
2016-10-19 15:45 ` Eryndlia Mavourneen
2016-10-19 15:53 ` Eryndlia Mavourneen
2 siblings, 1 reply; 10+ messages in thread
From: Dmitry A. Kazakov @ 2016-10-18 16:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
2016-10-18 16:03 ` Dmitry A. Kazakov
@ 2016-10-19 1:39 ` Luke A. Guest
2016-10-19 7:33 ` Dmitry A. Kazakov
2016-10-20 0:59 ` Randy Brukardt
0 siblings, 2 replies; 10+ messages in thread
From: Luke A. Guest @ 2016-10-19 1:39 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
2016-10-19 1:39 ` Luke A. Guest
@ 2016-10-19 7:33 ` Dmitry A. Kazakov
2016-10-20 0:59 ` Randy Brukardt
1 sibling, 0 replies; 10+ messages in thread
From: Dmitry A. Kazakov @ 2016-10-19 7:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
2016-10-19 1:39 ` Luke A. Guest
2016-10-19 7:33 ` Dmitry A. Kazakov
@ 2016-10-20 0:59 ` Randy Brukardt
1 sibling, 0 replies; 10+ messages in thread
From: Randy Brukardt @ 2016-10-20 0:59 UTC (permalink / raw)
"Luke A. Guest" <laguest@archeia.com> wrote in message
news:647636100.498533813.258228.laguest-archeia.com@nntp.aioe.org...
> 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?
Depends on the implementation of the storage pool, of course. The amount of
memory used by objects can be figured out at compile-time (assuming that the
subtype is definite and there aren't any discriminant-dependent components -
it's possible to declare such objects non-contiguously), but the pool will
have some overhead.
Besides, that's irrelevant. S'Max_Storage_Size_in_Elements is not a static
attribute and thus doesn't have to be calculatable at compile-time. The OP's
example is legal because the value of Storage_Size doesn't have to be
static, either. Of course, that means that whatever the OP is trying to do
probably isn't going to happen here.
Turning to the OP's question:
I would never expect to be able say anything useful about the size of a task
object - it's going to have to be allocated in pieces all over the memory
map (there's limits on where the stack can be allocated, for instance). No
attribute (Size, Object_Size, Max_Storage_Size_in_Elements) can have
anything useful to say about non-contiguous objects.
Note: I've always interpreted Max_Storage_Size_in_Elements to apply to a
single call to Allocate; there might be multiple calls to Allocate to
allocate a single object (Janus/Ada works this way; there is a separate call
to Allocate for each contiguous part of an object). Indeed, I wrote the
definition of the attribute with this model in mind. Whether any other Ada
lawyers would agree with me is unclear. :-)
Randy.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
2016-10-18 15:26 ` Vratislav Podzimek
2016-10-18 16:03 ` Dmitry A. Kazakov
@ 2016-10-19 15:45 ` Eryndlia Mavourneen
2016-10-19 15:53 ` Eryndlia Mavourneen
2 siblings, 0 replies; 10+ messages in thread
From: Eryndlia Mavourneen @ 2016-10-19 15:45 UTC (permalink / raw)
On Tuesday, October 18, 2016 at 10:26:28 AM UTC-5, Vratislav Podzimek 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. 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. 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.
There is another use for the attribute Max_Size_In_Storage_Elements. That is to allow a dynamic allocation on the stack for an object whose size and subtype you may not know until run-time. This can occur when receiving messages over a communications link or when reading from a loosely-defined file. This type of thing, otherwise, is not good design and is questionable even in this case.
-- Eryndlia
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
2016-10-18 15:26 ` Vratislav Podzimek
2016-10-18 16:03 ` Dmitry A. Kazakov
2016-10-19 15:45 ` Eryndlia Mavourneen
@ 2016-10-19 15:53 ` Eryndlia Mavourneen
2 siblings, 0 replies; 10+ messages in thread
From: Eryndlia Mavourneen @ 2016-10-19 15:53 UTC (permalink / raw)
On Tuesday, October 18, 2016 at 10:26:28 AM UTC-5, Vratislav Podzimek 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. 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. 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.
There is another use for the attribute Max_Size_In_Storage_Elements. That is to allow a dynamic allocation on the stack for an object whose size and subtype you may not know until run-time and for mapping using along with using the 'Address attribute for mapping these subtypes. This can occur when receiving messages over a communications link or when reading from a loosely-defined file. This type of thing, otherwise, is not good design and is questionable even in this case.
-- Eryndlia
^ permalink raw reply [flat|nested] 10+ messages in thread