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: 
 border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ludovic Brenta <ludovic@ludovic-brenta.org>
Newsgroups: comp.lang.ada
Subject: Re: Increasing GNAT's heap
Date: Wed, 13 Nov 2013 23:08:56 +0100
Organization: A noiseless patient Spider
Message-ID: <8761rwhs3r.fsf@ludovic-brenta.org>
References: <1o29hesl8k6yk$.1kqputng2vdks$.dlg@40tude.net>
 <87habgiufi.fsf@ludovic-brenta.org>
 <1ogylkzganxtj.1fuy036v94ui4$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="d46e6434f8e66b4835c82e1b4dd9d890";
 logging-data="11421"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX19Tc4F9FGaz0ROAFDmmMblO"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:3TFOxG/d4PZ9nWe92OKqyAJNs2k=
 sha1:HqZzuaD57II68TV/oic7gxp9fW4=
Xref: number.nntp.dca.giganews.com comp.lang.ada:183867
Date: 2013-11-13T23:08:56+01:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Wed, 13 Nov 2013 09:21:05 +0100, Ludovic Brenta wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> Does anybody know a way to increase the heap size available for GNAT? It
>>> crashes with famous GNAT BUG DETECTED, Storage_Error heap exhausted.
>>>
>>> GNAT 4.6.4 under Debian, testing, 32-bit
>> 
>> Presuming the heap is really exhausted (i.e. the command "free" shows no
>> free physical RAM and no free swap space left, and the command "top"
>> shows the gnat1 process consuming close to 4 GiB of resident memory)
>> then I'd suggest that you cannot increase the heap.  So, you should
>> compile smaller source files.
>
> It is 8GB RAM allowed for the virtual machine.
>
> Are you sure about 4GB? Doesn't Linux reserve some address space for its
> the kernel? Under Windows, where GNAT has same problems I cannot get more
> than 2GB. There is a boot switch to allow 3GB but it does not work well
> with GNAT. When GNAT is running under 64-bit Windows it goes through being
> 32-bit itself. From this I conclude that true 4GB under Linux would be
> enough to compile it.

You did mention "GNAT 4.6.4 under Debian, testing, 32-bit".  Now the
actual amount of virtual address space available to a 32-bit process
under Linux depends on the Linux kernel:

pure 32-bit kernel => 2 or 3 GiB, depending on configuration
32-bit kernel with PAE => 4 GiB per process
64-bit kernel => 4 GiB per 32-bit process

>> I'd try to identify which subprogram causes the problem and place
>> that subprogram in a compilation unit of its own (e.g. a private
>> child unit).
>
> It is always generic instances in the case of GNAT. It appears that
> the GNAT compilation model is not very much separate compilation. A
> compiled generic package instance does not reduce the amount of memory
> required later at the point when another body with/use it. The
> compiler starts frantically allocating huge amounts of memory,
> expanding generics, I suppose. This is how it comes to gigabytes when
> compiling a mere 100-liner.

Then maybe you should try placing the instantiation of your generic into
a package of its own, thereby breaking a chain of instantiations?  An
ugly workaround may be to declare a package with subprograms, all of
which rename the subprograms defined by a generic instantiation that is
hidden in the body, e.g.

generic
   type Element (<>) is private;
package Huge_Generic_G is -- consumes lots of RAM in the compiler
   procedure A (E : in out Element);
end Huge_Generic_G; -- body omitted

package Huge_Generic_Instantiation -- compiled separately
   type Element is record ... end record;
   procedure A (E : in out Element);
end Huge_Generic_Instantiation;

with Huge_Generic_G;
package body Huge_Generic_Instantiation is
   The_Instantiation_That_Consumes_Lots_Of_Memory is
     new Huge_Generic_G (Element => Element);
   procedure A (E : in out Element)
     renames The_Instantiation_That_Consumes_Lots_Of_Memory.A;
end Huge_Generic_G;

?

-- 
Ludovic Brenta.