From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Bug in GNAT? - Max_size_in_storage_elements insufficient Date: Tue, 18 Oct 2016 18:03:41 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: XXXaKfQ6zzC8DMOzOT/pgA.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:45.0) Gecko/20100101 Thunderbird/45.4.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:32123 Date: 2016-10-18T18:03:41+02:00 List-Id: On 2016-10-18 17:26, Vratislav Podzimek wrote: > On Tue, 18 Oct 2016 14:35:15 +0200, Dmitry A. Kazakov wrote: > >> On 18/10/2016 13:17, Vratislav Podzimek wrote: >> >>> Or am I missing something? >> >> A storage pool requires additional space to organize its structure and >> maintain its state. Depending on the method it is usually impossible to >> estimate the exact number of object the pool may hold. It depends on >> the individual sizes of the objects, the history of object's allocation >> and deallocation, the history of claiming the memory for the parts of >> the pool from the OS (a pool can be segmented). > > Well, then it's at least a bug in [Barnes] because there's an example > like the above ones just with a simpler type. But I still think the idea > here is/was to provide enough space for N items of some type. I am not sure if that were technically possible. Considering an implementation of, for example, a marked-margins pool, the penalty to have a guarantee would be extremely high. > That's what > the 'Max_size_in_storage_elements' attribute should be good for. And > there's no fragmentation nor history of allocation/deallocation in my > case. You don't know the implementation of. A segmented pool may request system memory on demand adapting the size of segments to the allocation requests: Max (Chunk size, Requested size). > If I specify I want space for 4 records, I should get space for 4 > records. Not slightly less due to some hidden, unpredictable overhead. If you know the pool size in advance and the objects in it, why don't you use a custom pool backed by an array? An arena pool would be exactly for this and trivial to implement in Ada. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de