Version 1.2 of ai05s/ai05-0193-1.txt

Unformatted version of ai05s/ai05-0193-1.txt version 1.2
Other versions for file ai05s/ai05-0193-1.txt

!standard 13.11(1/2)          09-11-03 AI05-0193-1/01
!standard 13.11.1 (0)
!class amendment 09-11-03
!status work item 09-11-03
!status received 09-06-16
!priority Low
!difficulty Easy
!qualifier Omission
!subject Alignment of allocators
!summary
Implementations may request more strictly aligned data for allocators.
!problem
In the case of an allocator of access type whose Storage_Pool is user-defined, RM 13.11(16) completely specifies the value of the Alignment parameter passed in the associated call to Allocate.
This may be inappropriate in some cases. If an implementation chooses to allocate space for additional (typically contiguous) data, the alignment requirements of this additional data may be stricter than the specified Alignment value. In this case, the implementation should have the freedom to pass in an Alignment value that reflects this requirement.
Consider the following example:
type T is access String; for T'Storage_Pool use ... ; X : T := new String'("abc");
In the case of an access type whose designated subtype is an unconstrained array subtype, some implementations prepend contiguous dope information to the allocated array. String'Alignment is typically 1. If the dope information contains values of the array type's index type(s), then the alignment requirement of this dope information might reasonably be that of the most strictly aligned index type. The given example might be easier to implement if the implementation were allowed to pass Integer'Alignment instead of String'Alignment as the Alignment parameter in the call to Allocate associated with the allocator.
As another example, consider the case of an implementation which (for whatever reason - finalization or deallocation) chooses to maintain a linked list of the allocated objects associated with an access type. Suppose further that the implementation chooses to implement this by prepending contiguous linkage fields to each allocated object. If the language definition requires passing in an Alignment value less than System.Address'Alignment, this requirement can be inconvenient.
As a third example, consider the case of an allocated coextension which has a stricter alignment requirement than that of the access-discriminant-bearing "owner" type.
The Max_Size_In_Storage_Units attribute was designed to cope with all of these issues as they relate to the value of the Size_In_Storage_Elements parameter value that is passed to Allocate. An analogous attribute is needed for the Alignment parameter.
!proposal
(see wording)
!wording
In 13.11(1/36), replace
The Alignment parameter is D'Alignment if D is a specific type, and otherwise is the alignment of the specific type identified by the tag of the object being created.
with
The Alignment parameter is at least D'Alignment if D is a specific type, and otherwise is at least the alignment of the specific type identified by the tag of the object being created. The Alignment parameter is no more than D'Max_Alignment_For_Allocation.
Completely replace 13.11.1 with
13.11.1 Storage Allocation Attributes
The Max_Size_In_Storage_Units and Max_Alignment_For_Allocation attributes may be useful in writing user-defined pool types.
Static Semantics
For every subtype S, the following attributes are defined:
S'Max_Size_In_Storage_Elements
Denotes the maximum value for Size_In_Storage_Elements that could be requested by the implementation via Allocate for an access type whose designated subtype is S. The value of this attribute is of type universal_integer.
S'Max_Alignment_For_Allocation
Denotes the maximum value for Alignment that could be requested by the implementation via Allocate for an access type whose designated subtype is S. The value of this attribute is of type universal_integer.
For a type with access discriminants, these attributes account for any calls on Allocate that could be performed to provide space for coextensions associated with these discriminants.
Update Annex K accordingly.
!discussion
(presented in Steve's standard grocery list form)
Obviously the name of the new attribute is subject to change. For purposes of discussion, "Max_Alignment_For_Allocation" seems better than "Foo".
Is there any point in mentioning a lower bound on the value of the Alignment parameter; should the first sentence of the new wording for 13.6(16/2) be omitted? Compare the analogous wording for the Size_In_Storage_Elements parameter:
The Size_In_Storage_Elements parameter indicates the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements, where D is the designated subtype.
The phrase "associated with these discriminants" is intended to include the case of a coextension of a coextension.
!ACATS test
Create an ACATS C-Test to test the new attribute.
!appendix

From: Steve Baird
Sent: Tuesday, June 16, 2009  6:09 AM

[Posted version /01 of this AI. - ED]

****************************************************************

From: Tucker Taft
Sent: Tuesday, June 16, 2009  7:09 AM

I agree with this problem and your proposed solution.
I see no need for specifying a minimum alignment, since it is trivial to round
up to a greater alignment.  On the other hand, if a storage allocator is
suddenly handed a bigger alignment than it was prepared for, that could be a
real pain, so I agree with defining an attribute that specifies the max.  It
might also be nice to have a value in package Standard that specifies the
maximum value that this attribute would ever have, so that simple allocators can
simply return everything with that maximum alignment, and ignore the alignment
parameter completely.

****************************************************************

From: Bob Duff
Sent: Tuesday, June 16, 2009  9:50 AM

> It might also be nice to have
> a value in package Standard that specifies the maximum
                     ^^^^^^^^
Maybe you mean package System?

> value that this attribute would ever have, so that simple allocators
> can simply return everything with that maximum alignment, and ignore
> the alignment parameter completely.

GNAT supports crazy stuff like:

    for T'Alignment use 2**25;

so such a "simple allocator" would not be useful in GNAT.  Doesn't mean such a
constant shouldn't exist in the language.

Maybe we want (instead or in addition) the max alignment the impl will pass to
an allocator when there are no user-specified Alignment clauses.

Which might not be quite the same as the max alignment of any type chosen by
default (but that might be useful, too).

****************************************************************

From: Tucker Taft
Sent: Tuesday, June 16, 2009  10:32 AM

>> It might also be nice to have
>> a value in package Standard that specifies the maximum
>                      ^^^^^^^^
> Maybe you mean package System?

Yes, I meant System.

>> value that this attribute would ever have, so that simple allocators
>> can simply return everything with that maximum alignment, and ignore
>> the alignment parameter completely.
>
> GNAT supports crazy stuff like:
>
>     for T'Alignment use 2**25;

Really?  I could imagine it accepting something like that for a library-level
object's alignment, but for a type that seems very hard to support.

> so such a "simple allocator" would not be useful in GNAT.  Doesn't
> mean such a constant shouldn't exist in the language.
>
> Maybe we want (instead or in addition) the max alignment the impl will
> pass to an allocator when there are no user-specified Alignment clauses.

Yes, I suppose that would be more useful.
It would also be useful to have a maximum supported alignment for user-specified
*subtype* alignment clauses (and perhaps for objects as well).

> Which might not be quite the same as the max alignment of any type
> chosen by default (but that might be useful, too).

Yes, that too.  Sounds like a nice little collection of alignment limits.

****************************************************************

From: Robert Dewar
Sent: Wednesday, June 17, 2009  5:36 AM

> Really?  I could imagine it accepting something like that for a
> library-level object's alignment, but for a type that seems very hard
> to support.

No, you just allocate extra and waste some space. We have to have this
cirrcuitry anyway to meet existing rules of the language, e.g. when the storage
allocator/stack max alignment does not match. So it is no extra work to trigger
it in silly cases.

****************************************************************

From: Bob Duff
Sent: Wednesday, June 17, 2009  3:11 PM

> >     for T'Alignment use 2**25;
> Really?

Yup.  ;-)

>...I could imagine it accepting something like that  for a
>library-level object's alignment, but for a type that  seems very hard
>to support.

Well, having been involved in some bug fixing in this area, I guess I'd have to
agree with "hard".  Not terribly efficient, either.

****************************************************************

Questions? Ask the ACAA Technical Agent