From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:6214:13ee:: with SMTP id ch14mr3943974qvb.43.1631776379270; Thu, 16 Sep 2021 00:12:59 -0700 (PDT) X-Received: by 2002:a25:af49:: with SMTP id c9mr5176173ybj.432.1631776378968; Thu, 16 Sep 2021 00:12:58 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 16 Sep 2021 00:12:58 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=87.88.29.208; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 87.88.29.208 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Subject: Re: Custom Storage Pool questions From: Emmanuel Briot Injection-Date: Thu, 16 Sep 2021 07:12:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:62751 List-Id: I am the original implementor of GNATCOLL.Storage_Pools.Headers, and I have= been silent in this discussion because I must admit I forgot a lot of the = details... To be sure, we did not add new attributes just for the sake of G= NATCOLL, those existed previously so likely had already found other uses. As has been mentioned several time in the discussion, the compiler is alrea= dy passing the full size it needs to Allocate, and the storage pool only ne= eds to allocate that exact amount in general. This applies for the usual ki= nds of storage pools, which would for instance preallocate a pool for objec= ts of fixed sizes, or add stronger alignment requirements. In the case of the GNATCOLL headers pool, we need to allocate more because = the user wants to store extra data. For that data, we are left on our own t= o find the number of bytes we need, which is part of the computation we do:= we of course need the number of bytes for the header's object_size, but al= so perhaps some extra bytes that are not returned by that object_size in pa= rticular for controlled types and arrays. Note again that those additional bytes are for the header type, not for the= type the user is allocating (for which, again, the compiler already passes= the number of bytes it needs). The next difficulty is then to convert from the object's 'Address back to y= our extra header data. This is when you need to know the size of the prefix= added by the compiler (array bounds, tag,...) to skip them and then take i= nto account the alignment, and finally the size of your header. Dmitry's suggested exercice (storing the timestamp of the allocation) seems= like a useful one indeed. It would be nice indeed if GNATCOLL's code was t= oo complicated, but I am afraid this isn't the case. We had used those pool= s to implement reference counting for various complex types, and ended up w= ith that complexity. AdaCore (Olivier Hainque) has made a change to the implementation since the= blog was published (https://github.com/AdaCore/gnatcoll-core/commits/maste= r/src/gnatcoll-storage_pools-headers.adb), so I got some details wrong in t= he initial implementation apparently. Emmanuel