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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,ae395e5c11de7bc9
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news1.google.com!goblin2!goblin1!goblin.stu.neva.ru!feeder.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Warren <ve3wwg@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: segfault with large-ish array with GNAT
Date: Thu, 18 Mar 2010 17:03:19 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <Xns9D3F84CEB288DWarrensBlatherings@85.214.113.135>
References: 
 <642ddf8b-1d45-4f74-83ad-2c755040ca33@k24g2000pro.googlegroups.com>
 <cf178987-c893-4e93-83b7-c86b6aeeac48@q15g2000yqj.googlegroups.com>
 <4ba13454$0$6720$9b4e6d93@newsspool2.arcor-online.net>
 <ac4bed10-f655-4fa5-8891-2967ba4388a0@k6g2000prg.googlegroups.com>
Injection-Date: Thu, 18 Mar 2010 17:03:19 +0000 (UTC)
Injection-Info: news.motzarella.org; posting-host="9f8M0iN5t54V+4DF/iqO8g";
	logging-data="27518"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/MhUbapG6xU17veH2N9anXiJPTMyYw8hY="
User-Agent: Xnews/5.04.25
X-Face: 
 &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j
Cancel-Lock: sha1:11J8BvwZ86qUybnkIQLT/kLDmno=
Xref: g2news2.google.com comp.lang.ada:10625
Date: 2010-03-18T17:03:19+00:00
List-Id: <comp.lang.ada>

Jerry expounded in news:ac4bed10-f655-4fa5-8891-2967ba4388a0
@k6g2000prg.googlegroups.com:
..
> So here's me being naive: I would have thought that Ada (or GNAT
> specifically) would be smart enough to allocate memory for large
> objects such as my long array in a transparent way so that I don't
> have to worry about it, thus (in the Ada spirit) making it harder to
> screw up. 

Programmer's do still have some responsibility in
design, Ada or otherwise. ;-)

> But it seems that I will have to allocate memory for large objects
> using pointers (and thus take the memory from the heap). Is that
> right?
..
> Jerry

The stack is a valuable resource and sometimes you need to
be careful with allocation.  I forget how gnat implements
tasks (threads) precisely, but they too require a stack. So 
your virtual address space for stack must also be carved up 
for each additional task. A 2G address space seemed huge 20 
years ago, but it seems rather small these days.

With the new focus on parallel cores etc., I've often pondered 
what a future CPU without a stack might look like. Imagine 
a CPU that somehow in microcode was able to do a fast-malloc 
of a stack frame (as part of a call), linking the new 
frame back to the calling frame. Then you could eliminate
the need for a "linear virtual stack region" altogether. This 
would allow code to freely fork into many parallel 
threads without the issue of pre-allocating stack [address]
space to each new thread. When the called procedure executed
a "return", it would (in microcode) free the current stack
frame and return to the prior one.  The "call" allocate/free's
could be constrained to one general "stack heap".

[..back from the day-dream..]

Generally speaking, large objects are best allocated
from the heap. But don't forget to release them once
finished. Otherwise you'll only feed from that trough 
a few times also. ;-)

Warren