Questions on Storage Pools

Questions on Storage Pools

[AdaMagica]

This is a question to language lawyers.

First two citations:

RM 13.11(18) If Storage_Size is specified for an access type, then the Storage_Size of this pool is at least that requested, and the storage for the pool is reclaimed when the master containing the declaration of the access type is left.

RM 7.6.1(11.1/3) Each nonderived access type T has an associated *collection*, which is the set of objects created by allocators of T ... Finalization of a collection consists of finalization of each object in the collection, in an arbitrary order. The collection of an access type is an object implicitly declared at the following place:
(11.2/3) For a named access type, the first freezing point (see 13.14) of the type.

So, IIUC 7.6.1, if the master of an access type is left, all still existing objects in the collection are finalized. (Note that these paragraphs and the definition of *collection* are new in Ada 2012.)
However 13.11 seems to say that this is the case only for access types with Storage_Size defined.

Further: If several access types use the same (user defined) storage pool, and the master of one of them is left (i.e. this access type has a deeper access level than the others and also deeper than the storage pool itself), is then the associated collection (i.e. a part of all objects allocated in the storage pool) finalized?
In other words: Is the collection of an access type with a defined storage pool part of this pool and finalized separately?

I would be very thankful for clarification.
C. Grein

Re: Questions on Storage Pools

[Adam Beneschan]

I think you're confusing "finalization" with "storage reclamation".  They're not the same thing.  Finalization mostly means calling Finalize routines on an object and its subcomponents, where they exist; there are extra actions for protected types.  Finalization doesn't even have to involve any freeing of storage.  If a Finalize routine does free storage, it would normally do so with Unchecked_Deallocation.  But it wouldn't deallocate the object being finalized, since Finalize's parameter is the object itself as an IN OUT parameter, not an access to the object.  

An access type can have a Storage_Size clause, or it can have a Storage_Pool clause.  It cannot have both (13.11(3)).  If it has a Storage_Size clause, the intent is that some block of memory (whose size is Storage_Size plus possibly a little extra) is set aside, and all "new" operations that return the access type use memory in that block for the new object.  If the object contains accesses to other objects (of a different access type), those accessed objects wouldn't be in the same block.  It would make sense for a Finalize procedure to deallocate those accessed objects, but that wouldn't affect what happens in the block of size Storage_Size.

If there's still something that isn't clear, I'll try to answer.

                                -- Adam
  

On Saturday, August 10, 2013 2:45:20 PM UTC-7, AdaMagica wrote:
> This is a question to language lawyers.
> 
> First two citations:
> 
> RM 13.11(18) If Storage_Size is specified for an access type, then the Storage_Size of this pool is at least that requested, and the storage for the pool is reclaimed when the master containing the declaration of the access type is left.
> 
> 
> 
> RM 7.6.1(11.1/3) Each nonderived access type T has an associated *collection*, which is the set of objects created by allocators of T ... Finalization of a collection consists of finalization of each object in the collection, in an arbitrary order. The collection of an access type is an object implicitly declared at the following place:
> 
> (11.2/3) For a named access type, the first freezing point (see 13.14) of the type.
> 
> 
> 
> So, IIUC 7.6.1, if the master of an access type is left, all still existing objects in the collection are finalized. (Note that these paragraphs and the definition of *collection* are new in Ada 2012.)
> 
> However 13.11 seems to say that this is the case only for access types with Storage_Size defined.
> 
> Further: If several access types use the same (user defined) storage pool, and the master of one of them is left (i.e. this access type has a deeper access level than the others and also deeper than the storage pool itself), is then the associated collection (i.e. a part of all objects allocated in the storage pool) finalized?
> 
> In other words: Is the collection of an access type with a defined storage pool part of this pool and finalized separately?
> 
> I would be very thankful for clarification.
> 
> C. Grein

Re: Questions on Storage Pools

[AdaMagica]

On Monday, August 12, 2013 7:14:23 PM UTC+2, Adam Beneschan wrote:
> I think you're confusing "finalization" with "storage reclamation".  They're not the same thing.

I guess you're right. The dust falling out of the worn RM is clearing now.
Thanx Adam.

> An access type can have a Storage_Size clause, or it can have a Storage_Pool clause.  It cannot have both (13.11(3)).

Yes, I know.

> If it has a Storage_Size clause, the intent is that some block of memory (whose size is Storage_Size plus possibly a little extra) is set aside, and all "new" operations that return the access type use memory in that block for the new object.

I understand and know this. But: Is there a GNAT GPL 2013 bug in this program:

  declare
    type Dyn is new Ada.Finalization.Controlled with record
      I: Integer;
    end record;
    overriding procedure Finalize (X: in out Dyn) is
    begin
      Put_Line ("Finalizing" & Integer'Image (X.I));
    end Finalize;
    type Dyn_Access is access Dyn
      with Storage_Size => 100;
    procedure Free is new Ada.Unchecked_Deallocation (Dyn, Dyn_Access);
    -- Dyn_Access is frozen here, so the collection is implicitly defined here.
    Ptr: array (1 .. 5) of Dyn_Access;
  begin
    Ptr (1) := new Dyn'(Ada.Finalization.Controlled with I => 1);
    Ptr (2) := new Dyn'(Ada.Finalization.Controlled with I => 2);
    Ptr (3) := new Dyn'(Ada.Finalization.Controlled with I => 3);
    Free (Ptr (2));  -- Finalize is called here
    Ptr (2) := new Dyn'(Ada.Finalization.Controlled with I => 4);
    -- RM 7.6.1(11.1/3)
    -- Each nonderived access type T has an associated collection, which is the set of objects
    -- created by allocators of T... Unchecked_Deallocation removes an object from its collection.
    -- Finalization of a collection consists of finalization of each object in the collection,
    -- in an arbitrary order. The collection of an access type is an object implicitly declared
    -- at the following place:
    -- RM 7.6.1(11.2/3)
    -- For a named access type, the first freezing point (see 13.14) of the type.
    -- RM 13.11(18)
    -- If Storage_Size is specified for an access type, then ... the storage for the pool is
    -- reclaimed when the master containing the declaration of the access type is left.
    Put_Line ("Must finalize collection now and reclaim pool storage.");
  end;  -- no Finalize called here!

There is no finalization of the still existing allocated objects. The collection is dying, so it should be finalized and with it all still existing allocated objects. It's irrelevant if there is the aspect Storage_Size or not.

If there is Storage_Size, the storage will be freed. If there is none, the storage remains allocated (with finalized objects inside). Correct?

Re: Questions on Storage Pools

[Adam Beneschan]

On Tuesday, August 13, 2013 12:36:08 PM UTC-7, AdaMagica wrote:

> I understand and know this. But: Is there a GNAT GPL 2013 bug in this program:
> [snipped]

> There is no finalization of the still existing allocated objects. The collection is dying, so it should be finalized and with it all still existing allocated objects. It's irrelevant if there is the aspect Storage_Size or not.
> 
> If there is Storage_Size, the storage will be freed. If there is none, the storage remains allocated (with finalized objects inside). Correct?

I believe this is correct, although off the top of my head I think that if there's no Storage_Size clause, the implementation is still allowed to deallocate the storage if it chooses.  

But yes, when the end of the block is reached, the three not-yet-deallocated objects should be finalized.  In fact, if you remove the Free call, then when the end of the block is reached, all four objects should have Finalized called on them, even though one of those objects now has nothing pointing to it.  

At least I think this is still correct.  Some relevant paragraphs got changed in Ada 2012.  I don't think they affect your example, but I'm planning to look more carefully.

                                -- Adam

 

Re: Questions on Storage Pools

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@aol.com> wrote in message 
news:b59a8382-d34e-47d6-8c29-290b1683ac3b@googlegroups.com...
On Tuesday, August 13, 2013 12:36:08 PM UTC-7, AdaMagica wrote:
...
>> If there is Storage_Size, the storage will be freed. If there is none, 
>> the storage
>> remains allocated (with finalized objects inside). Correct?
>
>I believe this is correct, although off the top of my head I think that if 
>there's no
>Storage_Size clause, the implementation is still allowed to deallocate the 
>storage if it chooses.
>
>But yes, when the end of the block is reached, the three 
>not-yet-deallocated objects should
>be finalized.  In fact, if you remove the Free call, then when the end of 
>the block is reached,
>all four objects should have Finalized called on them, even though one of 
>those objects now
>has nothing pointing to it.
>
>At least I think this is still correct.  Some relevant paragraphs got 
>changed in Ada 2012.
> I don't think they affect your example, but I'm planning to look more 
> carefully.

The reason that the wording changed was that anonymous access types were 
poorly specified if the designated object was finalizable. We needed to say 
where that finalization would happen. There was no intent to change any 
behavior of named access types, and I believe that your explanation is 
correct.

                                            Randy.

Re: Questions on Storage Pools

[AdaMagica]

Thank you both, Adam and Randy, your explanations were most helpful.

I'll file a bug report to AdaCore.

Christoph