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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Thu, 20 Aug 2020 18:25:46 -0500 Organization: JSA Research & Innovation Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Injection-Date: Thu, 20 Aug 2020 23:25:47 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29118"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:59770 List-Id: "Dmitry A. Kazakov" 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.