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!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: The future of Spark . Spark 2014 : a wreckage
Date: Thu, 11 Jul 2013 07:19:56 +0100
Organization: A noiseless patient Spider
Message-ID: <lyppupvcs3.fsf@pushface.org>
References: <d84b2eb2-eab3-4dec-917c-0498473c1e93@googlegroups.com>
	<krfb56$332$1@loke.gir.dk>
	<7ebe0439-fa4c-4374-a6c7-365ac78e6e39@googlegroups.com>
	<krkums$ldf$1@loke.gir.dk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="c8504a89c76ea11bda6664e6198ae3cd";
	logging-data="22245"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18jHr1GlLftTaAb7sEOAzy+gIHSxdK2iiU="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
Cancel-Lock: sha1:NpRmjhymiyyWTmMLn7Fs01N7kcQ=
	sha1:z8iXCXc9sn8VQkatgQQMQClofcc=
Xref: news.eternal-september.org comp.lang.ada:16286
Date: 2013-07-11T07:19:56+01:00
List-Id: <comp.lang.ada>

"Randy Brukardt" <randy@rrsoftware.com> writes:

> problems with fragmentation. (Although those are way overblown,
> they're very unlikely to occur in practice.)

That depends on the capabilities of your OS's memory manager! In our
VxWorks 5.5/Ada 95 system, it didn't take long for the heap to become so
fragmented that the system couldn't meet real-time constraints (such as
failing to kick the watchdog timer).

It was a fairly straightforward job to provide our own version of GNAT's
System.Memory to use preallocated binary-sized bins (we instrumented it
to determine the maximum number of blocks for each bin and allocated
that number at startup, with the ability to allocate further blocks at
run time if the measured maximum requirement grew).

I don't remember why use of Ada storage pools wasn't the right solution;
maybe the some of the allocations were by the runtime without the option
to use a user-defined storage pool? (things like task control blocks).