Re: Ada containers and custom allocators

[Robert A Duff <bobduff@shell01.TheWorld.com>]

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

> Yes, of course. It could be used for performance monitoring as well. But I
> wouldn't characterize it as "many" interesting optimizations, it's more like
> a few interesting things. But it isn't valuable enough to force every user
> of a container to define a storage pool (since there is no name for a
> standard storage pool).

That seems easy enough to fix.  Simply have a predefined function:

    type Storage_Pool_Pointer is access all Root_Storage_Pool'Class;
    function Default_Storage_Pool return Storage_Pool_Pointer;

and use that for the default in the generic.

Default_Storage_Pool must be general enough to support any size.
There's no requirement that this be the same pool used by
default for misc access types.


>... And we needed to keep the number of standard
> containers manageable.

I suppose, but we weren't shy about writing macros in English -- see for
example package Float_Text_IO.  It would take one paragraph in the RM
to double the number of container packages by having versions with
a Pool parameter.  Pretty ugly, but there's precedent.

>> [...]
>> > (or, the
>> > storage pool passed would have to be completely general, allowing any
> size
>> > allocation, which would eliminate the vast majority of interesting
> things
>> > that you can do with storage pools).
>>
>> There are ways to overcome this problem, at least for some container
>> types. Node-based containers could use fixed-size allocators, but of
>> course it is the container which would then instantiate the allocator
>> with the proper node size. It was possible in C++.
>
> Only if you put severe limits on the implementations. For one thing, you
> would need to know the fixed node size in the storage pool in order to take
> any realistic advantage of it, but you couldn't ask the container's
> implementation for that size since you'd have to pass the storage pool to
> the instance. The only practical way to do that is to *require* a particular
> node layout. We might as well just standardize the source code of the
> container body in that case.
>
> Moreover, there is no requirement in Ada that objects be laid out
> continuously.

Perhaps there should be!

But anyway, given this fact, user-defined storage pools need to be fully
general (accept any size), or else depend on details of the Ada
implementation.  This is not specific to containers.

>...Janus/Ada will often make several allocator calls when
> allocating parts of an object, and those calls will all be different sizes.
> That's especially true inside of a generic body, where essentially
> everything that depends on a formal type is of an unknown size and thus has
> to be allocated separately. Even if you had the source code of the body, it
> probably would make different calls to Storage_Pool.Allocate on Janus/Ada
> and on GNAT.
>
> We'd also have to define what operations can calls the allocators.

I don't see why.

> Currently, there are no such restrictions on the containers implementation.
>
> Also, of course, it would only work for a couple of the containers. All of
> the hashed forms also are going to allocate the hash table, so there are
> going to be odd-size allocations (more than just nodes). And the vectors are
> likely to allocate chunks of various sizes.

It can work -- you just can't take advantage of (say) fixed sized
chunks.  I guess what you're saying is that that defeats the main
purpose!

> The net effect is that this is not possible to define (or use) in any
> useful, portable way. (If you're willing to stick to a single vendor, then
> it is more possible, but that of course has nothing to do with the
> standard.) Combined with the inability to name the standard storage pool,
> there isn't much point in doing this for the primary containers.
>
> The basic idea of the containers was to define a specification, and allow
> implementers to innovate on the implementations. (They don't even have to be
> in Ada.) The extra specification required to allow passing in a storage pool
> would seriously reduce these possibilities.
>
> The bounded forms seem to allow even better control over dynamic allocation
> (by not having any in the common case, although that surely wouldn't be true
> for Janus/Ada), are much easier to use (don't have to write a storage pool),
> and would work for the high-intergrity types that cannot allow an allocator
> near their program. Thus, they're the first focus of work. There are a lot
> of other ideas, but I can't say what if anything will come of them.

- Bob