From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Thu, 20 Aug 2020 19:49:34 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Content-Language: en-US X-Mozilla-News-Host: news://news.aioe.org X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:59766 List-Id: On 20/08/2020 02:13, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:rgr27b$1o1n$2@gioia.aioe.org... >> On 10/08/2020 02:31, Randy Brukardt wrote: >>> This is not that hard to deal with. Janus/Ada handles >>> discriminant-dependent >>> components of mutable objects this way: they are allocated on the stack, >>> but >>> if they have to be reallocated they move to the heap. >> >> 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. >>> 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de