segfault with large-ish array with GNAT
in [ADA]
|
From: tmoran on 18 Mar 2010 12:46 > 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. (Like not having to worry about whether arguments to > subprograms are passed by value or by reference--it just happens.) > > 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? A couple of years ago I wrote some code to look at the (large) Netflix data set. It used Janus Ada and ran in a 2 GB Windows system. I thought about switching to Gnat (for faster floating point) but discovered that would require changing all large arrays to heap allocation, so I dropped that idea. IMO, that's a ridiculous limitation in this day and age.
From: Warren on 18 Mar 2010 13:03 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
From: Warren on 18 Mar 2010 15:11 expounded in news:hntlcq$u1t$1(a)speranza.aioe.org: >> 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. (Like not having to worry about whether arguments to >> subprograms are passed by value or by reference--it just happens.) >> >> 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? > A couple of years ago I wrote some code to look at the (large) Netflix > data set. It used Janus Ada and ran in a 2 GB Windows system. I thought > about switching to Gnat (for faster floating point) but discovered that > would require changing all large arrays to heap allocation, so I dropped > that idea. IMO, that's a ridiculous limitation in this day and age. 2gb is wayyy too small. ;-) Warren
From: Adam Beneschan on 18 Mar 2010 15:51 On Mar 18, 3:13 am, Jeffrey Creem <j...(a)thecreems.com> wrote: > > As for wishing that the compiler would automatically switch between heap > and stack, that would probably be a terrible idea and render the > language quite unsuitable for embedded systems. Ummm, you're mixing two things there. The *language* is suitable for embedded systems. The language does not dictate anything about where things are stored, and nobody is asking for the Ada standard to require that every Ada implementation be able to allocate every large local array it sees. Not every compiler that compiles the language will be suitable for embedded systems, but that's not a bad thing--- not everyone who uses an Ada compiler is using it for embedded systems, and those that aren't shouldn't mind if their particular Ada *implementation* does things in a way that's not suitable for embedded systems. I don't see a problem with a compiler generating code to allocate arrays on the heap that it knows will be large, or supporting a pragma that tells it to put arrays on the heap. -- Adam
From: Maciej Sobczak on 18 Mar 2010 16:38
On 18 Mar, 18:03, Warren <ve3...(a)gmail.com> wrote: > 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 There is no need to do that in microcode - the compiler decides what does it mean to call a subprogram and what does it mean to allocate the "frame", so you might simply have a compiler that implements these concepts in terms of a dynamically allocated linked list. I vaguely remember reading about a C compiler that did exactly that a while ago - but I fail to find it in Google due to the noise from billions of tutorials with stacks and lists. :-) Today you might find this idea implemented in just about any *interpreter*. -- Maciej Sobczak * www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4/ |