Re: Proposal: Auto-allocation of Indefinite Objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:rhmd3c$1eql$1@gioia.aioe.org...
> On 20/08/2020 02:13, Randy Brukardt wrote:
...
>>> What you do if such an object is allocated via pool-specific access 
>>> type?
>>
>> The whole object goes in that pool. The entire mechanism in Janus/Ada is
>> built around pools - the stack is represented by a pool object as well as
>> various other pools to support the mechanism.
>
> OK, but then you are back to the problem that you do not know how that 
> pool works. The user pool might require a certain order of objects inside 
> it and your interference with relocation will break it.

Such a pool does not implement the interface as defined in 13.11. It's OK of 
course to write a pool that depends on implementation-specific properties 
(I've done it many times), but such a pool is not usable with portable Ada 
code. If the pool allows any sort of allocation at any time, then it will 
work just fine with the Janus/Ada implementation.

(Of course, you can use a one-size only pool allocation with Janus/Ada, so 
long as what you are allocating doesn't have discrimiant-dependent 
components. Janus/Ada has informational messages about such components, so 
you can do it if you want/need. Probably should have an aspect as well to 
force an error if a static size is expected.)

Note that this is the reason that Ada doesn't support specifying the pool 
used by a container. It would not be reasonable to restrict the allocations 
in any way, so implementation-dependent pool designs would not work.

>>>> I note that the original idea already exists for discriminant-dependent
>>>> components -- that's a bit more painful to use but hardly difficult. 
>>>> The
>>>> main issue is that most compilers fail to support these components 
>>>> properly,
>>>> using some sort of max-size implementation unconditionally rather than
>>>> switching to a pool-based implementation when the max size is too 
>>>> large.
>>>> I've never understood why Ada compilers were allowed to make such a
>>>> limitation (it becomes a major limitation when working on non-embedded
>>>> programs), while similar limitations on case statements and aggregates
>>>> are not allowed.
>>>
>>> I think a non-embedded target could use a task-local pool for the 
>>> purpose.
>>
>> At the cost of using explicit allocators and effectively leaking memory
>> (most tasks are fairly long-lived, much longer than the majority of
>> objects).
>
> No, I meant that if you used a pool behind the scenes for local objects 
> you could do that task-specific eliminating interlocking.

Whether that would be worthwhile would depend on how expensive the locking 
is. If a lock-free algorithm was used, it might be cheap enough to not make 
it worth bothering (the actual heap manipulation usually being more 
expensive given the free chain searching). [A lock-free algorithm typically 
using busy-waiting rather than suspension to wait.]

Of course, Janus/Ada itself uses the Windows heap for heap management, so 
the locking is already built-in and not paying for it is not an option. But 
roll-your-own-heap managers (as Janus/Ada used on CP/M and MS-DOS) have 
options.

                                Randy.