On 2021-09-17 01:21, Jere wrote:

> I appreciate the clarity and apologize if I caused too much of a stir.

It is not that we have huge traffic in c.l.a.

> I was asking the question
> because I didn't understand, so I hope you don't think too poorly of me for it, despite my mistake.

Nope, especially because the issue with X'Address being unusable for
memory pool developers is a long standing painful problem that need to
be resolved. That will never happen until a measurable group of people
start asking questions. So you are doubly welcome.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Nope, especially because the issue with X'Address being unusable for
> memory pool developers is a long standing painful problem that need to
> be resolved. That will never happen until a measurable group of people
> start asking questions. So you are doubly welcome.

There are two attributes that we should all have known about,
Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
(storage units, I think, introduced in 2017)

[1]
https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat_rm/implementation_defined_attributes.html#attribute-descriptor-size
[2]
https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat_rm/implementation_defined_attributes.html#attribute-finalization-size

On 2021-09-17 21:46, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Nope, especially because the issue with X'Address being unusable for
>> memory pool developers is a long standing painful problem that need to
>> be resolved. That will never happen until a measurable group of people
>> start asking questions. So you are doubly welcome.
>
> There are two attributes that we should all have known about,
> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
> (storage units, I think, introduced in 2017)

They are non-standard and have murky semantics I doubt anybody really
cares about.

What is needed is the address passed to Deallocate should the object be
freed = the address returned by Allocate. Is that too much to ask?

BTW, finalization lists (#2) should have been removed from the language
long ago. They have absolutely no use, except maybe for debugging, and
introduce huge overhead. The semantics should have been either
Unchecked_Deallocation or compiler allocated objects/components may call
Finalize, nothing else.

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

On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
> On 2021-09-17 21:46, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Nope, especially because the issue with X'Address being unusable for
>>> memory pool developers is a long standing painful problem that need to
>>> be resolved. That will never happen until a measurable group of people
>>> start asking questions. So you are doubly welcome.
>>
>> There are two attributes that we should all have known about,
>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>> (storage units, I think, introduced in 2017)
>
> They are non-standard and have murky semantics I doubt anybody really
> cares about.
>
> What is needed is the address passed to Deallocate should the object be
> freed = the address returned by Allocate. Is that too much to ask?

That is already required by RM 13.11(21.7/3): "The value of the
Storage_Address parameter for a call to Deallocate is the value returned
in the Storage_Address parameter of the corresponding successful call to
Allocate."

The "size" parameters are also required to be the same in the calls to
Deallocate and to Allocate.

> BTW, finalization lists (#2) should have been removed from the language
> long ago.

Huh? Where does the RM _require_ finalization lists? I see them
mentioned here and there as a _possible_ implementation technique, and
an alternative "PC-map" technique is described in RM 7.6.1 (24.r .. 24.t).

On 2021-09-17 23:17, Niklas Holsti wrote:
> On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
>> On 2021-09-17 21:46, Simon Wright wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> Nope, especially because the issue with X'Address being unusable for
>>>> memory pool developers is a long standing painful problem that need to
>>>> be resolved. That will never happen until a measurable group of people
>>>> start asking questions. So you are doubly welcome.
>>>
>>> There are two attributes that we should all have known about,
>>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>>> (storage units, I think, introduced in 2017)
>>
>> They are non-standard and have murky semantics I doubt anybody really
>> cares about.
>>
>> What is needed is the address passed to Deallocate should the object
>> be freed = the address returned by Allocate. Is that too much to ask?
>
> That is already required by RM 13.11(21.7/3): "The value of the
> Storage_Address parameter for a call to Deallocate is the value returned
> in the Storage_Address parameter of the corresponding successful call to
> Allocate."

You missed the discussion totally. It is about X'Address attribute.

The challenge: write pool with a function returning object allocation
time by its pool-specific access type.

>> BTW, finalization lists (#2) should have been removed from the
>> language long ago.
>
> Huh? Where does the RM _require_ finalization lists?

7.6.1 (11 1/3)

> I see them
> mentioned here and there as a _possible_ implementation technique, and
> an alternative "PC-map" technique is described in RM 7.6.1 (24.r .. 24.t).

I don't care about techniques to implement meaningless stuff. It should
be out, at least there must be a representation aspect for turning this
mess off.

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

On 2021-09-18 10:49, Dmitry A. Kazakov wrote:
> On 2021-09-17 23:17, Niklas Holsti wrote:
>> On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
>>> On 2021-09-17 21:46, Simon Wright wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>
>>>>> Nope, especially because the issue with X'Address being unusable for
>>>>> memory pool developers is a long standing painful problem that need to
>>>>> be resolved. That will never happen until a measurable group of people
>>>>> start asking questions. So you are doubly welcome.
>>>>
>>>> There are two attributes that we should all have known about,
>>>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>>>> (storage units, I think, introduced in 2017)
>>>
>>> They are non-standard and have murky semantics I doubt anybody really
>>> cares about.
>>>
>>> What is needed is the address passed to Deallocate should the object
>>> be freed = the address returned by Allocate. Is that too much to ask?
>>
>> That is already required by RM 13.11(21.7/3): "The value of the
>> Storage_Address parameter for a call to Deallocate is the value
>> returned in the Storage_Address parameter of the corresponding
>> successful call to Allocate."
>
> You missed the discussion totally. It is about X'Address attribute.

Sure, I understand that the address returned by Allocate, and passed to
Deallocate, for an object X, is not always X'Address, and that you would
like some means to get the Allocate/Deallocate address from (an access
to) X. But what you stated as not "too much to ask" is specifically
required in the RM paragraph I quoted. Perhaps you meant to state
something else, about X'Address or some other attribute, but that was
not what you wrote.

Given that an object can be allocated in multiple independent pieces, it
seems unlikely that what you want will be provided. You would need some
way of iterating over all the pieces allocated for a given object, or
some way of defining a "main" or "prime" piece and a means to get the
Allocate/Deallocate address for that piece.

>>> BTW, finalization lists (#2) should have been removed from the
>>> language long ago.
>>
>> Huh? Where does the RM _require_ finalization lists?
>
> 7.6.1 (11 1/3)

RM (2012) 7.6.1 (11.1/3) says only that objects must be finalized in
reverse order of their creation. There is no mention of "list".

>> I see them mentioned here and there as a _possible_ implementation
>> technique, and an alternative "PC-map" technique is described in RM
>> 7.6.1 (24.r .. 24.t).
>
> I don't care about techniques to implement meaningless stuff. It should
> be out, at least there must be a representation aspect for turning this
> mess off.

Then your complaint seems to be about something specified for the order
of finalization, but you haven't said clearly what that something is.

On 2021-09-18 11:03, Niklas Holsti wrote:
> On 2021-09-18 10:49, Dmitry A. Kazakov wrote:
>> On 2021-09-17 23:17, Niklas Holsti wrote:
>>> On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
>>>> On 2021-09-17 21:46, Simon Wright wrote:
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>
>>>>>> Nope, especially because the issue with X'Address being unusable for
>>>>>> memory pool developers is a long standing painful problem that
>>>>>> need to
>>>>>> be resolved. That will never happen until a measurable group of
>>>>>> people
>>>>>> start asking questions. So you are doubly welcome.
>>>>>
>>>>> There are two attributes that we should all have known about,
>>>>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>>>>> (storage units, I think, introduced in 2017)
>>>>
>>>> They are non-standard and have murky semantics I doubt anybody
>>>> really cares about.
>>>>
>>>> What is needed is the address passed to Deallocate should the object
>>>> be freed = the address returned by Allocate. Is that too much to ask?
>>>
>>> That is already required by RM 13.11(21.7/3): "The value of the
>>> Storage_Address parameter for a call to Deallocate is the value
>>> returned in the Storage_Address parameter of the corresponding
>>> successful call to Allocate."
>>
>> You missed the discussion totally. It is about X'Address attribute.
>
>
> Sure, I understand that the address returned by Allocate, and passed to
> Deallocate, for an object X, is not always X'Address, and that you would
> like some means to get the Allocate/Deallocate address from (an access
> to) X. But what you stated as not "too much to ask" is specifically
> required in the RM paragraph I quoted. Perhaps you meant to state
> something else, about X'Address or some other attribute, but that was
> not what you wrote.

I wrote about attributes, specifically GNAT-specific ones used in the
blog to calculate the correct address. "Too much to ask" was about an
attribute that would return the object address directly.

> Given that an object can be allocated in multiple independent pieces, it
> seems unlikely that what you want will be provided.

Such implementations would automatically disqualify the compiler.
Compiler-generated piecewise allocation is OK for the stack, not for
user storage pools.

And anyway, all this equally applies to X'Address.

>>>> BTW, finalization lists (#2) should have been removed from the
>>>> language long ago.
>>>
>>> Huh? Where does the RM _require_ finalization lists?
>>
>> 7.6.1 (11 1/3)
>
>
> RM (2012) 7.6.1 (11.1/3) says only that objects must be finalized in
> reverse order of their creation. There is no mention of "list".

It talks about "collection."

> Then your complaint seems to be about something specified for the order
> of finalization, but you haven't said clearly what that something is.

No, it is about the overhead of maintaining "collections" associated
with an access type in order to call Finalization for all members of the
collection.

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

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Not sure what you are expecting. There is no requirement that objects
> are allocated contigiously. Indeed, Janus/Ada will call Allocate as
> many times as needed for each object; for instance, unconstrained
> arrays are in two parts (descriptor and data area).

The referenced blog[1] says

"As we mentioned before, we need to ensure that the bounds for
unconstrained arrays are stored next to the element, not in a
separate memory block, to improve performance. This is done by
setting the Size attribute on the type. When we set this size to
that of a standard pointer, GNAT automatically changes the layout,
so that we now have:

+-------+------+---------+
| First | Last | Element |
+-------+------+---------+

I _think_ I was aware of this before, in fact I remember using it, but
not where! Is it documented anywhere?

[1] https://blog.adacore.com/header-storage-pools

On 2021-09-18 13:22, Dmitry A. Kazakov wrote:
> On 2021-09-18 11:03, Niklas Holsti wrote:
>> On 2021-09-18 10:49, Dmitry A. Kazakov wrote:
>>> On 2021-09-17 23:17, Niklas Holsti wrote:
>>>> On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
>>>>> On 2021-09-17 21:46, Simon Wright wrote:
>>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>>
>>>>>>> Nope, especially because the issue with X'Address being unusable for
>>>>>>> memory pool developers is a long standing painful problem that
>>>>>>> need to
>>>>>>> be resolved. That will never happen until a measurable group of
>>>>>>> people
>>>>>>> start asking questions. So you are doubly welcome.
>>>>>>
>>>>>> There are two attributes that we should all have known about,
>>>>>> Descriptor_Size[1] (bits, introduced in 2011) and
>>>>>> Finalization_Size[2]
>>>>>> (storage units, I think, introduced in 2017)
>>>>>
>>>>> They are non-standard and have murky semantics I doubt anybody
>>>>> really cares about.
>>>>>
>>>>> What is needed is the address passed to Deallocate should the
>>>>> object be freed = the address returned by Allocate. Is that too
>>>>> much to ask?
>>>>
>>>> That is already required by RM 13.11(21.7/3): "The value of the
>>>> Storage_Address parameter for a call to Deallocate is the value
>>>> returned in the Storage_Address parameter of the corresponding
>>>> successful call to Allocate."
>>>
>>> You missed the discussion totally. It is about X'Address attribute.
>>
>>
>> Sure, I understand that the address returned by Allocate, and passed
>> to Deallocate, for an object X, is not always X'Address, and that you
>> would like some means to get the Allocate/Deallocate address from (an
>> access to) X. But what you stated as not "too much to ask" is
>> specifically required in the RM paragraph I quoted. Perhaps you meant
>> to state something else, about X'Address or some other attribute, but
>> that was not what you wrote.
>
> I wrote about attributes, specifically GNAT-specific ones used in the
> blog to calculate the correct address.

You wrote about the attributes in an earlier paragraph, not the one that
said "too much to ask" -- see the quotes above. But ok, enough said.

> "Too much to ask" was about an
> attribute that would return the object address directly.
>
>> Given that an object can be allocated in multiple independent pieces,
>> it seems unlikely that what you want will be provided.
>
> Such implementations would automatically disqualify the compiler.
> Compiler-generated piecewise allocation is OK for the stack, not for
> user storage pools.

That is your opinion (or need), to which you are entitled, of course,
but it is not an RM requirement on compilers -- see Randy's posts about
what Janus/Ada does.

>>>>> BTW, finalization lists (#2) should have been removed from the
>>>>> language long ago.
>>>>
>>>> Huh? Where does the RM _require_ finalization lists?
>>>
>>> 7.6.1 (11 1/3)
>>
>>
>> RM (2012) 7.6.1 (11.1/3) says only that objects must be finalized in
>> reverse order of their creation.

Oops, I quoted the above from 7.6.1 (11/3), which specifies the order of
finalization in another case (finalization of a master). RM 7.6.1
(11.1/3) leaves the order arbitrary for the finalization of a collection.

>> There is no mention of "list".
>
> It talks about "collection."
>
>> Then your complaint seems to be about something specified for the
>> order of finalization, but you haven't said clearly what that
>> something is.
>
> No, it is about the overhead of maintaining "collections" associated
> with an access type in order to call Finalization for all members of the
> collection.

So you want a way to specify that for a given access type, although the
accessed object type has a Finalize operation or needs finalization, the
objects left over in the (at least conceptually) associated collection
should _not_ be finalized when the scope of the access type is left?
Have you proposed this to the ARG?

To me it seems a risky think to do, subverting the normal semantics of
initialization and finalization. Perhaps it could be motivated for
library-level collections in programs that are known to never terminate
(that is, to not need any clean-up when they do stop or are stopped).

On 2021-09-18 17:59, Niklas Holsti wrote:

> So you want a way to specify that for a given access type, although the
> accessed object type has a Finalize operation or needs finalization, the
> objects left over in the (at least conceptually) associated collection
> should _not_ be finalized when the scope of the access type is left?

Exactly, especially because these objects are not deallocated, as you
say they are left over. If they wanted GC they should do that. If they
do not, then they should keep their hands off the objects maintained by
the programmer.

> To me it seems a risky think to do, subverting the normal semantics of
> initialization and finalization.

Quite the opposite, it is the collection rule that subverts semantics
because objects are not freed, yet mangled.

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

On 2021-09-18 19:19, Dmitry A. Kazakov wrote:
> On 2021-09-18 17:59, Niklas Holsti wrote:
>
>> So you want a way to specify that for a given access type, although
>> the accessed object type has a Finalize operation or needs
>> finalization, the objects left over in the (at least conceptually)
>> associated collection should _not_ be finalized when the scope of the
>> access type is left?
>
> Exactly, especially because these objects are not deallocated, as you
> say they are left over. If they wanted GC they should do that. If they
> do not, then they should keep their hands off the objects maintained by
> the programmer.
>
>> To me it seems a risky think to do, subverting the normal semantics of
>> initialization and finalization.
>
> Quite the opposite, it is the collection rule that subverts semantics
> because objects are not freed, yet mangled.

Local variables declared in a subprogram are also not explicitly freed
(deallocated), yet they are automatically finalized when the subprogram
returns.

My understanding of Ada semantic principles is that any object that is
initialized should also be finalized. Since the objects left in a
collection associated with a local access type become inaccessible when
the scope of the access type is left, finalizing them automatically,
even without an explicit free, makes sense to me. If you disagree,
suggest a change to the ARG and see if you can find supporters.

Has this feature of Ada caused you real problems in real applications,
or is it only a point of principle for you?

On 2021-09-19 12:36, Niklas Holsti wrote:
> On 2021-09-18 19:19, Dmitry A. Kazakov wrote:
>> On 2021-09-18 17:59, Niklas Holsti wrote:
>>
>>> So you want a way to specify that for a given access type, although
>>> the accessed object type has a Finalize operation or needs
>>> finalization, the objects left over in the (at least conceptually)
>>> associated collection should _not_ be finalized when the scope of the
>>> access type is left?
>>
>> Exactly, especially because these objects are not deallocated, as you
>> say they are left over. If they wanted GC they should do that. If they
>> do not, then they should keep their hands off the objects maintained
>> by the programmer.
>>
>>> To me it seems a risky think to do, subverting the normal semantics
>>> of initialization and finalization.
>>
>> Quite the opposite, it is the collection rule that subverts semantics
>> because objects are not freed, yet mangled.
>
> Local variables declared in a subprogram are also not explicitly freed
> (deallocated), yet they are automatically finalized when the subprogram
> returns.

Local objects are certainly freed. Explicit or not, aggregated or not,
is irrelevant.

> My understanding of Ada semantic principles is that any object that is
> initialized should also be finalized.

IFF deallocated.

An application that runs continuously will never deallocate, HENCE
finalize certain objects.

> Has this feature of Ada caused you real problems in real applications,
> or is it only a point of principle for you?

1. It is a massive overhead in both memory and performance terms with no
purpose whatsoever. I fail to see where that sort of thing might be even
marginally useful. Specialized pools, e.g. mark-and-release will deploy
their own bookkeeping, not rely on this.

2. What is worse that a collection is not bound to the pool. It is to an
access type, which may have a narrower scope. So the user could declare
an unfortunate access type, which would corrupt objects in the pool and
the pool designer has no means to prevent that.

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

Followup question cause Randy's statement (below) got me thinking:
If a compiler is allowed to break up an allocation into multiple
calls to Allocate (and of course Deallocate), how does one go about
enforcing that the user's header is only created once? In the example
Randy gave (unconstrained arrays), in Janus there is an allocation for the
descriptor and a separate allocation for the data. If I am making a storage
pool that is intending to create a hidden header for my objects, this means
in Janus Ada (and potentially other compilers) I would instead create two
headers, one for the descriptor and one for the data, when I might intend
to have one header for the entire object.

On Monday, September 13, 2021 at 1:29:39 AM UTC-4, Randy Brukardt wrote:
> Not sure what you are expecting. There is no requirement that objects are
> allocated contigiously. Indeed, Janus/Ada will call Allocate as many times
> as needed for each object; for instance, unconstrained arrays are in two
> parts (descriptor and data area).
>
> <SNIPPED>
>
> Randy.
>
>
> "Jere" <> wrote in message
> news:e3c5c553-4a7f-408a...@googlegroups.com...
> >I was learning about making user defined storage pools when
> > I came across an article that made me pause and wonder how
> > portable storage pools actually can be. In particular, I assumed
> > that the Size_In_Storage_Elements parameter in the Allocate
> > operation actually indicated the total number of storage elements
> > needed.
> >
> > <SNIPPED>
> >

On 2021-09-20 3:31, Jere wrote:
> Followup question cause Randy's statement (below) got me thinking:
> If a compiler is allowed to break up an allocation into multiple
> calls to Allocate (and of course Deallocate), how does one go about
> enforcing that the user's header is only created once?

I think one cannot enforce that, because the calls to Allocate do not
indicate (with parameters) which set of calls concern the same object
allocation.

This is probably why Dmitry said that such compiler behaviour would
"disqualify the compiler" for his uses.

> > If a compiler is allowed to break up an allocation into multiple
> > calls to Allocate (and of course Deallocate), how does one go about
> > enforcing that the user's header is only created once?
> I think one cannot enforce that, because the calls to Allocate do not
> indicate (with parameters) which set of calls concern the same object
> allocation.

I think the only solution would be for this compiler to have another attribute similar to 'Storage_Pool, but that would define the pool for the descriptor:

for X'Storage_Pool use Pool;
for X'Descriptor_Storage_Pool use Other_Pool;

That way the user can decide when to add (or not) extra headers.

On 2021-09-19 14:41, Dmitry A. Kazakov wrote:
> On 2021-09-19 12:36, Niklas Holsti wrote:
>> On 2021-09-18 19:19, Dmitry A. Kazakov wrote:
>>> On 2021-09-18 17:59, Niklas Holsti wrote:
>>>
>>>> So you want a way to specify that for a given access type, although
>>>> the accessed object type has a Finalize operation or needs
>>>> finalization, the objects left over in the (at least conceptually)
>>>> associated collection should _not_ be finalized when the scope of
>>>> the access type is left?
>>>
>>> Exactly, especially because these objects are not deallocated, as you
>>> say they are left over. If they wanted GC they should do that. If
>>> they do not, then they should keep their hands off the objects
>>> maintained by the programmer.
>>>
>>>> To me it seems a risky think to do, subverting the normal semantics
>>>> of initialization and finalization.
>>>
>>> Quite the opposite, it is the collection rule that subverts semantics
>>> because objects are not freed, yet mangled.
>>
>> Local variables declared in a subprogram are also not explicitly freed
>> (deallocated), yet they are automatically finalized when the
>> subprogram returns.
>
> Local objects are certainly freed. Explicit or not, aggregated or not,
> is irrelevant.

Objects left over in a local collection may certainly be freed
automatically, if the implementation has created a local pool for them.
See ARM 13.11 (2.a): "Alternatively, [the implementation] might choose
to create a new pool at each accessibility level, which might mean that
storage is reclaimed for an access type when leaving the appropriate scope."

>> My understanding of Ada semantic principles is that any object that is
>> initialized should also be finalized.
>
> IFF deallocated.
>
> An application that runs continuously will never deallocate, HENCE
> finalize certain objects.

And I agreed that in this case it could be nice to let the programmer
specify that keeping collections is not needed.

>> Has this feature of Ada caused you real problems in real applications,
>> or is it only a point of principle for you?
>
> 1. It is a massive overhead in both memory and performance terms with no
> purpose whatsoever. [...]

Have you actually measured or observed that overhead in some application?

> 2. What is worse that a collection is not bound to the pool. It is to an
> access type, which may have a narrower scope. So the user could declare
> an unfortunate access type, which would corrupt objects in the pool and
> the pool designer has no means to prevent that.

So there is a possibility of programmer mistake, leading to unintended
finalization of those (now inaccessible) objects.

However, your semantic argument (as opposed to the overhead argument)
seems to be based on an assumption that the objects "left over" in a
local collection, and which thus are inaccessible, will still, somehow,
participate in the later execution of the program, which is why you say
that finalizing those objects would "corrupt" them.

It seems to me that such continued participation is possible only if the
objects contain tasks or are accessed through some kind of unchecked
programming. Do you agree?

On 2021-09-20 08:48, Emmanuel Briot wrote:
>>> If a compiler is allowed to break up an allocation into multiple
>>> calls to Allocate (and of course Deallocate), how does one go about
>>> enforcing that the user's header is only created once?
>> I think one cannot enforce that, because the calls to Allocate do not
>> indicate (with parameters) which set of calls concern the same object
>> allocation.
>
> I think the only solution would be for this compiler to have another attribute similar to 'Storage_Pool, but that would define the pool for the descriptor:
>
> for X'Storage_Pool use Pool;
> for X'Descriptor_Storage_Pool use Other_Pool;
>
> That way the user can decide when to add (or not) extra headers.

This will not work with arenas and stack pools. And it is error-prone
because the attribute is associated with the access type. Furthermore,
it is the descriptor you wanted to tag with extra data.

One could add another primitive operation to Root_Storage_Pool:

procedure Allocate_Secondary (
Pool : in out Root_Storage_Pool;
Storage_Address : out Address;
Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
Alignment : in Storage_Elements.Storage_Count;
Segment_No : in Positive); -- Re-dispatches to Allocate

The object allocation protocol would be:

Allocate_Secondary (Pool, ..., 1);
Allocate_Secondary (Pool, ..., 2);
...
Allocate_Secondary (Pool, ..., N);
Allocate (Pool, ...); -- Header goes here

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

On 2021-09-20 09:05, Niklas Holsti wrote:
> On 2021-09-19 14:41, Dmitry A. Kazakov wrote:
>> On 2021-09-19 12:36, Niklas Holsti wrote:
>>> On 2021-09-18 19:19, Dmitry A. Kazakov wrote:
>>>> On 2021-09-18 17:59, Niklas Holsti wrote:
>>>>
>>>>> So you want a way to specify that for a given access type, although
>>>>> the accessed object type has a Finalize operation or needs
>>>>> finalization, the objects left over in the (at least conceptually)
>>>>> associated collection should _not_ be finalized when the scope of
>>>>> the access type is left?
>>>>
>>>> Exactly, especially because these objects are not deallocated, as
>>>> you say they are left over. If they wanted GC they should do that.
>>>> If they do not, then they should keep their hands off the objects
>>>> maintained by the programmer.
>>>>
>>>>> To me it seems a risky think to do, subverting the normal semantics
>>>>> of initialization and finalization.
>>>>
>>>> Quite the opposite, it is the collection rule that subverts
>>>> semantics because objects are not freed, yet mangled.
>>>
>>> Local variables declared in a subprogram are also not explicitly
>>> freed (deallocated), yet they are automatically finalized when the
>>> subprogram returns.
>>
>> Local objects are certainly freed. Explicit or not, aggregated or not,
>> is irrelevant.
>
> Objects left over in a local collection may certainly be freed
> automatically, if the implementation has created a local pool for them.
> See ARM 13.11 (2.a): "Alternatively, [the implementation] might choose
> to create a new pool at each accessibility level, which might mean that
> storage is reclaimed for an access type when leaving the appropriate
> scope."

May or may not. The feature which correctness depends on scopes and lots
of further assumptions has no place in a language like Ada.

>>> Has this feature of Ada caused you real problems in real
>>> applications, or is it only a point of principle for you?
>>
>> 1. It is a massive overhead in both memory and performance terms with
>> no purpose whatsoever. [...]
>
> Have you actually measured or observed that overhead in some application?

How?

However you could estimate it from the most likely implementation as a
doubly-linked list. You add new element for each allocation and remove
one for each deallocation. The elements are allocated in the same pool
or in some other pool. Finalization is not time bounded, BTW. Nice?

>> 2. What is worse that a collection is not bound to the pool. It is to
>> an access type, which may have a narrower scope. So the user could
>> declare an unfortunate access type, which would corrupt objects in the
>> pool and the pool designer has no means to prevent that.
>
> So there is a possibility of programmer mistake, leading to unintended
> finalization of those (now inaccessible) objects.
>
> However, your semantic argument (as opposed to the overhead argument)
> seems to be based on an assumption that the objects "left over" in a
> local collection, and which thus are inaccessible, will still, somehow,
> participate in the later execution of the program, which is why you say
> that finalizing those objects would "corrupt" them.
>
> It seems to me that such continued participation is possible only if the
> objects contain tasks or are accessed through some kind of unchecked
> programming. Do you agree?

No. You can have them accessible over other access types with wider scopes:

Collection_Pointer := new X;
Global_Pointer := Collection_Pointer.all'Unchecked_Access;

access discriminants etc. As I said, hands off!

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

On 2021-09-20 10:35, Dmitry A. Kazakov wrote:
> On 2021-09-20 09:05, Niklas Holsti wrote:

[snipping context]

>> However, your semantic argument (as opposed to the overhead argument)
>> seems to be based on an assumption that the objects "left over" in a
>> local collection, and which thus are inaccessible, will still,
>> somehow, participate in the later execution of the program, which is
>> why you say that finalizing those objects would "corrupt" them.
>>
>> It seems to me that such continued participation is possible only if
>> the objects contain tasks or are accessed through some kind of
>> unchecked programming. Do you agree?
>
> No. You can have them accessible over other access types with wider scopes:
>
>    Collection_Pointer := new X;
>    Global_Pointer := Collection_Pointer.all'Unchecked_Access;
>

So, unchecked programming, as I said.

On 2021-09-20 10:08, Niklas Holsti wrote:
> On 2021-09-20 10:35, Dmitry A. Kazakov wrote:

>> No. You can have them accessible over other access types with wider
>> scopes:
>>
>>     Collection_Pointer := new X;
>>     Global_Pointer := Collection_Pointer.all'Unchecked_Access;
>>
> So, unchecked programming, as I said.

Right, working with pools is all that thing. Maybe "new" should be named
"unchecked_new" (:-))

Finalize and Initialize certainly should have been Unchecked_Finalize
and Unchecked_Initialize as they are not enforced. You can override the
parent's Initialize and never call it. It is a plain primitive
operations anybody can call any time any place. You can even call it
before the object is fully initialized!

So, why bother with objects the user manually allocates (and forgets to
free)?

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

On Monday, September 20, 2021 at 12:48:21 AM UTC-6, briot.e wrote:
> > > If a compiler is allowed to break up an allocation into multiple
> > > calls to Allocate (and of course Deallocate), how does one go about
> > > enforcing that the user's header is only created once?
> > I think one cannot enforce that, because the calls to Allocate do not
> > indicate (with parameters) which set of calls concern the same object
> > allocation.
> I think the only solution would be for this compiler to have another attribute similar to 'Storage_Pool, but that would define the pool for the descriptor:
>
> for X'Storage_Pool use Pool;
> for X'Descriptor_Storage_Pool use Other_Pool;
>
> That way the user can decide when to add (or not) extra headers.
Hmmm, smells like a place to use generics and subpools; perhaps something like:

Generic
Type Element(<>) is limited private;
Type Descriptor(<>) is limited private;
with Create( Item : Element ) return Descriptor;
Package Descriptor_Subpool is
Type Pool_Type is new System.Storage_Pools.Subpools.Root_Storage_Pool_With_Subpools with private;
Private
-- Element-subpool & descriptor-subpool defined here.
-- Allocation of element also allocates Descriptor.
End Descriptor_Subpool;

Just top-of-the-head musings though.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:shpf4d$1a6s$1@gioia.aioe.org...
> On 2021-09-14 02:48, Jere wrote:
....
> The problem with unconstrained arrays is not that the bounds are not
> allocated, they are, but the semantics of X'Address when applied to
> arrays.
>
> A'Address is the address of the first array element, not of the array
> object. For a pool designer it constitutes a problem of getting the array
> object by address. This is what Emmanuel discusses in the blog.

Right, this is why Janus/Ada never "fixed" 'Address to follow the Ada
requirement. (Our Ada 83 compiler treats the "object" as whatever the
top-level piece is, for an unconstrained array, that's the bounds -- the
data lies elsewhere and is separately allocated -- something that follows
from slice semantics.)

I suppose your suggestion of implementing yet-another-attribute is probably
the right way to go, and then finding every use of 'Address in existing RRS
Janus/Ada code and changing it to use the new attribute that works "right".

Randy.

> [ The motivation behind Ada choice was probably to keep the semantics
> implementation-independent. ]
>
> Consider for example a list of String elements. When Allocate is called
> with String, it returns the address of all String. But that is not the
> address you would get if you applied 'Address. You have to add/subtract
> some offset in order to get one from another.
>
> In Simple Components this offset is determined at run-time for each
> generic instance.
>
> Of course, a proper solution would be fixing Ada by adding another address
> attribute:
>
> X'Object_Address
>
> returning the first address of the object as allocated.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Sorry about that, I didn't understand what you were asking. And I get
defensive about people who think that a pool should get some specific Size
(and only that size), so I leapt to a conclusion and answered accordingly.

The compiler requests all of the memory IT needs, but if the pool needs some
additional memory for it's purposes (pretty common), it will need to add
that space itself. It's hard to imagine how it could be otherwise, I guess I
would have thought that goes without saying. (And that rather proves that
there is nothing that goes without saying.)

Randy.

"Jere" <jhb.chat@gmail.com> wrote in message
news:96e7199f-c354-402f-a6c6-2a0e042b6747n@googlegroups.com...
> On Wednesday, September 15, 2021 at 3:01:52 AM UTC-4, Simon Wright wrote:
>> Jere <> writes:
>>
>> > Thanks for the response. I'm sorry for all the questions. That's how
>> > I learn and I realize it isn't a popular way to learn in the
>> > community, but I have always learned very differently than most.
>> Seems to me you ask interesting questions which generate enlightening
>> responses!
> Thanks! though in this case, my question was ill formed after I missed a
> detail
> in the blog, so the mistake is on me. I will say I hold back some
> questions
> as it is very intimidating to ask on C.L.A. I mean the first response led
> off
> with "Not sure what you are expecting" so it is hard to know how to
> formulate
> a good question as I always seem to get some harsh responses (which I am
> sure is because I asked the question poorly). I'm unfortunately a very
> visual
> person and words are not my forte and I feel like when I ask questions
> about
> the boundaries of the language I manage to put folks on the defensive. I
> don't dislike Ada at all, it is my favorite language, but I think it is
> hard to
> craft questions on some topics without putting forth the impression that
> I don't like it, at least with my limited ability to word craft.

"J-P. Rosen" <rosen@adalog.fr> wrote in message
news:shpg9b$t23$1@dont-email.me...
> Le 14/09/2021 � 08:23, Dmitry A. Kazakov a �crit :
>> Of course, a proper solution would be fixing Ada by adding another
>> address attribute:
>>
>> X'Object_Address
>>
>> returning the first address of the object as allocated.
> But you cannot assume that the object is allocated as one big chunk.
> Bounds can be allocated at a different place. What would be
> X'Object_Address in that case?

The address of the real object, which is the bounds. (I'm using "object" in
the Janus/Ada compiler sense and not in the Ada sense.) The only way I could
make sense of the implementation requirements for Janus/Ada was to have
every object be statically sized. If the Ada object is *not* statically
sized, then the Janus/Ada object is a descriptor that provides access to
that Ada object data.

Generally, one wants access to the statically sized object, as that provides
access to everything else (there may be multiple levels if
discriminant-dependent arrays are involved). That's not what 'Address is
supposed to provide, so the address used internally to the compiler is the
wrong answer in Ada terms, but it is the right answer for most uses (storage
pools being an obvious example).

When one specifies 'Address in Janus/Ada, you are specifying the address of
the statically allocated data. The rest of the object lives in some storage
pool and it makes absolutely no sense to try to force that somewhere.

There's no sensible reason to expect 'Address to be
implementation-independent; specifying the address of unconstrained arrays
is nonsense unless you know that the same Ada compiler is creating the
object you are accessing -- hardly a common case.

Randy.

"Jere" <jhb.chat@gmail.com> wrote in message
news:036086ba-ea40-44cb-beb7-cded0f501cfbn@googlegroups.com...
> On Monday, September 13, 2021 at 1:29:39 AM UTC-4, Randy Brukardt wrote:
>> Not sure what you are expecting. There is no requirement that objects are
>> allocated contigiously. Indeed, Janus/Ada will call Allocate as many
>> times
>> as needed for each object; for instance, unconstrained arrays are in two
>> parts (descriptor and data area).
>>
> No expectations. Just questions. I wasn't concerned with whether the
> allocated memory was contiguous or not, but whether an implementation
> is required to supply the correct size of memory needed to allocate an
> object
> or if it is allowed to pass a value to Size that is less than the amount
> of
> memory actually needed. For example, the blog there indicates the
> maintainer of the custom storage pool needs to account for First/Last
> indexes of an unconstrained array separately instead of assuming that
> value is
> included as part of the Size parameter's value.
>
> If the Size parameter doesn't require that it includes space for
> First/Last
> for unconstrained arrays or Prev/Next for controlled objects (assuming
> that is even the implementation picked of course), then I'm not seeing
> a way to write a custom storage pool that is portable because you need
> to account for each implementation's "hidden" values that are not
> represented
> in the Size parameter.

No, that would be wrong. The implementation has to calculate the Size of
memory that it needs, no less.

> For example if Janus calculated Size to have
> both the size of the array and the size of First and Last but GNAT didn't
> and my storage pool assumed the JANUS method, then if someone
> used my storage pool with GNAT then it would access memory
> from some other location potentially and erroneously.

No. What you cannot assume is that all of the memory is allocated at once.
There can be multiple parts. But the compiler has to figure out the right
size for each part, it can't tell you it needs 8 bytes and use 10. That
would be a broken compiler.

>> The only thing that you can assume in a portable library is that you get
>> called the same number of times and sizes/alignment for Allocate and
>> Deallocate; there's no assumptions about size or alignment that you can
>> make.
> So to be clear, you cannot assume that Size and Alignment are appropriate
> for the actual object being allocated correct? Size could actually be
> less than the actual amount of memory needed and the alignment may only
> apply to part of the object being allocated, not the full object?

Yes and no. You can't assume anything about the Size and Alignment passed.
But whatever is passed has to be what the compiler actually needs.

> Is that correct? I'm asking because that is what the blog suggests with
> the example it gave.

The blog sounds like nonsense for most uses. It sounds like someone is
trying to do something very GNAT-specific -- and that's fine (I have lots of
pools that assume the size of array descriptors in Janus/Ada to separate
those from the array data allocations). But it's irrelevant for normal use.

>>
>> If you want to build a pool around some specific allocated size, then if
>> it
>> needs to be portable, (A) you have to calculate the allocated size, and
>> (B)
>> you have to have a mechanism for what to do if some other size is
>> requested.
>> (Allocate a whole block for smaller sizes, fall back to built-in heap for
>> too large is what I usually do).
>>
> Are there any good tricks to handle this? For example, if I design a
> storage pool around constructing a particular type of object, what is
> normally done to discourage another programmer from using the pool with
> an entirely different type? Maybe raise an exception if the size isn't
> exact?
> I'm not sure what else, unless maybe there is an Aspect/Attribute that
> can be set to ensure only a specific type of object can be constructed.

I either raise Program_Error (if I'm lazy), or simply hand off "wrong-sized"
allocations/deallocations to the standard Storage_Pool.

Randy.