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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,124905131f269735 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-26 22:06:13 PST From: Erik Johannessen Newsgroups: comp.lang.ada Subject: Re: gnat and heap size Date: 26 Sep 2001 22:45:02 +0200 Organization: Kongsberg Defence and Aerospace Message-ID: References: <1001442590.557811@news.drenet.dnd.ca> <3BB10E2C.8C57FFE1@linuxchip.demon.co.uk> NNTP-Posting-Host: 150.1.31.59 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Acadia) Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!uninett.no!Norway.EU.net!193.71.169.73!spiten.kongsberg.com!kongsberg!not-for-mail Xref: archiver1.google.com comp.lang.ada:13423 Date: 2001-09-26T22:45:02+02:00 List-Id: Ted Dennison writes: > In article , > Claude Marinier says... > > > >The application is an electromagnetic simulation. Yes, we could use sparse > >matrix techniques but part of the program requires a full matrix. Perhaps > >we are hitting a low level limit (is that what Adrian is saying?). > > If the small program you showed has the problem, then try the same > thing with a small C program. If *it* has the problem too, then you > have an OS issue that you should really take up with Solaris > experts. If it doesn't have the problem, then at the least you can There's no problem with malloc()'ing a 9000*9000*4 byte array on solaris, provided you have that much vmem available. In Claude's example if the array is declared as a constrained type gnat will warn that a storage error will be raised at runtime. As far as I can tell this happens when the size of the array in bits is larger than the largest positive value for a signed 32-bit integer. When using new to allocate the array gnat will apparently not do any checks for this. For the 9000x9000 array of float example it will request a negative size from gnat_malloc/malloc. An interesting consequence of this is that if you continue to increase the size of the array it will eventually get positive again, but the size will of course not match the real size of the array. The fun part here is that you can stay within the bounds you've declared for the array, but access memory outside of the area allocated for the array. If you've got other data on the heap after the array you'll get some interesting bugs. :) The following code demonstrates the problem with ada.text_io; procedure matrix is type matrix is array ( integer range <> ) of integer; type matrix_a is access matrix; a: matrix_a; b: matrix_a; begin a := New matrix( 1..152000000 ); b := New matrix( 1..100 ); for i in b'range loop b(i) := 0; end loop; a(17782318) := 42; for i in b'range loop if b(i) = 42 then ada.text_io.put_line("Found 42 at index " & integer'image(i) & " in b"); end if; b(i) := 0; end loop; end matrix; Compiled with gnat-3.14a1 on sparc-solaris2.6 I get: > ./matrix Found 42 at index 42 in b A quick glance at the gnat rm/ug did not turn up any information on this. Also, I haven't checked if there is a compiler switch which will turn on checks for this. -Erik -- /d{def}def/m{mul}d/a{add}d/q{repeat}d/y 1 d 300{/x 1 d 600{/c x 600 div 4 m 2 sub d/z y 300 div 2 m 1 sub d/r 0 d/i 0 d/t 0 d{t 1 le{/n r r m i i m sub c a d/b 2 r m i m z a d/r n d/i b d r r m i i m a 16 gt{exit}if} {exit}ifelse/t t .01 a d}loop t setgray x y moveto 1 1 rlineto stroke/x x 1 a d}q /y y 1 a d}q