* Ada memory management? @ 2004-10-07 9:39 matthias_k 2004-10-07 12:06 ` Martin Krischik 2004-10-07 17:24 ` Nick Roberts 0 siblings, 2 replies; 7+ messages in thread From: matthias_k @ 2004-10-07 9:39 UTC (permalink / raw) Hey there, since there is an allocator 'new' in Ada, I was wondering if there is a 'delete' too. I've heard there is a special technique called Storage Pool in Ada to write own memory managers, but what is the default deallocator? Consider this code: procedure Does_This_Leak is type Int_Ptr is access Integer; ptr: Int_Ptr; begin ptr := new Integer; end Does_This_Leak; Will this procedure leak? Or does Ada somehow deal on its own with the allocation. Thanks in advance, Matthias ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ada memory management? 2004-10-07 9:39 Ada memory management? matthias_k @ 2004-10-07 12:06 ` Martin Krischik 2004-10-07 17:24 ` Nick Roberts 1 sibling, 0 replies; 7+ messages in thread From: Martin Krischik @ 2004-10-07 12:06 UTC (permalink / raw) matthias_k wrote: > Hey there, > > since there is an allocator 'new' in Ada, I was wondering if there is a > 'delete' too. I've heard there is a special technique called Storage > Pool in Ada to write own memory managers, but what is the default > deallocator? Two option open: Your Ada has garbage collection or you use Ada.Unchecked_Deallocation. AFAIK: Only Ada's targeting the JVM have garbage collection. However for GNAT you can use the Boehm Collector which is part of the GCC. Mind you: A good collection class library will free you from almost all memory management. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ada memory management? 2004-10-07 9:39 Ada memory management? matthias_k 2004-10-07 12:06 ` Martin Krischik @ 2004-10-07 17:24 ` Nick Roberts 2004-10-07 19:04 ` Luke A. Guest 1 sibling, 1 reply; 7+ messages in thread From: Nick Roberts @ 2004-10-07 17:24 UTC (permalink / raw) matthias_k wrote: > Hey there, > > since there is an allocator 'new' in Ada, I was wondering if there is a > 'delete' too. I've heard there is a special technique called Storage > Pool in Ada to write own memory managers, but what is the default > deallocator? > > Consider this code: > > procedure Does_This_Leak is > type Int_Ptr is access Integer; > ptr: Int_Ptr; > begin > ptr := new Integer; > end Does_This_Leak; > > Will this procedure leak? Or does Ada somehow deal on its own with the > allocation. There are some Ada implementations where memory never leaks (unless a bug in the compiler or run time system causes one, or the programmer causes it by poor unchecked or external programming). Automatic deallocation combined with comprehensive memory reclamation is called 'full garbage collection'. I think, in reality, there is no native code Ada compiler which supports full garbage collection. Personally, I regret this situation. The compiler vendors all say they don't support full garbage collection because there is no demand, which is true considering the paying Ada compiler market is almost entirely made up of the embedded, real-time, and safety-critical arenas. But the fact that the Ada language is capable of protecting the programmer from the possibility of memory leaks used to be, many years ago, one of the reasons cited for its superiority. The complete lack of support for full garbage collection seems unfortunate to me. It is a proud capability of many languages which have since become far more popular than Ada. I am trying to build my own (open source, GPL) Ada compiler, and I hope to be able to build in full garbage collection support, if only to prove that it can be done. But I do not have recourse to huge resources, so don't hold your breath. http://sourceforge.net/projects/eclat I am a (moderate) fan of full garbage collection, but I concede that it is not, in reality, as useful as you might think. One could guess that 90% of 'desktop' Ada programs would not benefit from the availablity of full garbage collection, for one of the following reasons: the program does little or no dynamic memory allocation; the program does not give any (or much) opportunity for automatic deallocation until (near) the end of program execution; more control over the management of (most) dynamically allocated variables is required; the program must be written to be portable to other Ada compilers (which do not or may not support full garbage collection); the program only uses pre-written encapsulated 'containers' for dynamic data storage, which all do their own memory management anyway. Many programs will only dynamically allocate variables of a fixed size (known at compile time). By having a separate pool for each different size, the necessity for memory reclamation (moving things around) is obviated; only automatic deallocation is useful. I do not know if any existing native code Ada compiler actually supports this technique (doing it automatically). It could be done manually, by implementing one's own storage pool. Probably, full garbage collection would never be used for an embedded or real-time program, because it is a big-memory technique, and does not conform to strict timing requirements. I'm not quite sure about safety-critical programs. However, for the remaining 10% -- or whatever the figure really is -- of desktop programs, full garbage collection would certainly be a useful facility, and I am certain it is why many good programmers often choose languages such as Python, Ruby, and various others which support it, in preference to a language which (in practice) doesn't. -- Nick Roberts ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ada memory management? 2004-10-07 17:24 ` Nick Roberts @ 2004-10-07 19:04 ` Luke A. Guest 2004-10-07 22:52 ` ECLAT [was: Ada memory management?] Nick Roberts 0 siblings, 1 reply; 7+ messages in thread From: Luke A. Guest @ 2004-10-07 19:04 UTC (permalink / raw) On Thu, 07 Oct 2004 18:24:21 +0100, Nick Roberts wrote: > I am trying to build my own (open source, GPL) Ada compiler, and I hope to > be able to build in full garbage collection support, if only to prove that > it can be done. But I do not have recourse to huge resources, so don't hold > your breath. > > http://sourceforge.net/projects/eclat Erm, how far are you with this project Nick? I've known about it for a while and your page doesn't really have anything on it (yet), how about an update? Also, are you using GCC at all? That would be interesting; it might spur some competition with ACT ;-D If you're not using GCC, maybe you should try using it to speed up development. Luke. ^ permalink raw reply [flat|nested] 7+ messages in thread
* ECLAT [was: Ada memory management?] 2004-10-07 19:04 ` Luke A. Guest @ 2004-10-07 22:52 ` Nick Roberts 2004-10-08 18:16 ` Luke A. Guest 0 siblings, 1 reply; 7+ messages in thread From: Nick Roberts @ 2004-10-07 22:52 UTC (permalink / raw) Luke A. Guest wrote: >> http://sourceforge.net/projects/eclat > > Erm, how far are you with this project Nick? I've known about it for a > while and your page doesn't really have anything on it (yet), how about an > update? Honest truth is, not very far yet. There are a few docs under the 'Docs' link. > Also, are you using GCC at all? That would be interesting; it might spur > some competition with ACT ;-D If you're not using GCC, maybe you should > try using it to speed up development. I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in the front and and the back end. I think this is a case where it makes sense to 'reinvent the wheel'. If people who are new to Ada ask "Are there any free compilers?", I think it would sound a lot better to be able to suggest two, rather than just one. (I know there is ObjectAda, but it is really only a demo version.) There are some technical reasons why GNAT and GCC are unsuited to what I want to achieve. GNAT's library model is based on source code files directly representing the library; this model isn't always ideal. I want to provide a compiler that has the more traditional model of a library being stored in a set of files which contain all the necessary information (to generate executables) in a binary form. I want ECLAT to be able to target the AdaOS native executable format for the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is suitable (only) for a 'flat' memory model, and I think adapting it to generate code that supports the NEAI/IA-32 segmented architecture would be difficult. -- Nick Roberts ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ECLAT [was: Ada memory management?] 2004-10-07 22:52 ` ECLAT [was: Ada memory management?] Nick Roberts @ 2004-10-08 18:16 ` Luke A. Guest 2004-10-09 0:12 ` Nick Roberts 0 siblings, 1 reply; 7+ messages in thread From: Luke A. Guest @ 2004-10-08 18:16 UTC (permalink / raw) On Thu, 07 Oct 2004 23:52:57 +0100, Nick Roberts wrote: > Honest truth is, not very far yet. There are a few docs under the 'Docs' link. I'll have a look, but I have a feeling I may have already read them a while ago ;-) > I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in > the front and and the back end. I think this is a case where it makes > sense to 'reinvent the wheel'. If people who are new to Ada ask "Are > there any free compilers?", I think it would sound a lot better to be > able to suggest two, rather than just one. (I know there is ObjectAda, > but it is really only a demo version.) It would be two, two different front-ends to GCC, that makes two not one. > There are some technical reasons why GNAT and GCC are unsuited to what I > want to achieve. > > GNAT's library model is based on source code files directly representing > the library; this model isn't always ideal. I want to provide a compiler > that has the more traditional model of a library being stored in a set > of files which contain all the necessary information (to generate > executables) in a binary form. I'm not too sure what you mean here. The old/original way of handling libraries in Ada (AFAIK) uses a kind of repository where packages are added when they are compiled, and they have to be removed by hand. GNAT changes the standard Ada way of handling libraries, by using normal link libraries and a standard linker. The only source I see is in the adainclude dir where we have *.ali and *.ads files. > I want ECLAT to be able to target the AdaOS native executable format for > the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is > suitable (only) for a 'flat' memory model, and I think adapting it to > generate code that supports the NEAI/IA-32 segmented architecture would > be difficult. No offence, but your OS is not going to be too portable in the near future. Segmentation is being done away with in the 64-bit x86 CPU's AFAIR. Some CPU's don't support it at all (PPC). Either way, it would be possible to provide a flat-memory model ECLAT under GCC, via a front-end port. Luke. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ECLAT [was: Ada memory management?] 2004-10-08 18:16 ` Luke A. Guest @ 2004-10-09 0:12 ` Nick Roberts 0 siblings, 0 replies; 7+ messages in thread From: Nick Roberts @ 2004-10-09 0:12 UTC (permalink / raw) Luke A. Guest wrote: >>I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in >>the front and and the back end. I think this is a case where it makes >>sense to 'reinvent the wheel'. If people who are new to Ada ask "Are >>there any free compilers?", I think it would sound a lot better to be >>able to suggest two, rather than just one. (I know there is ObjectAda, >>but it is really only a demo version.) > > It would be two, two different front-ends to GCC, that makes two not one. Okay, but I particularly want to be able to offer a different back end, especially one that is written (substantially) in Ada. >>GNAT's library model is based on source code files directly representing >>the library; this model isn't always ideal. I want to provide a compiler >>that has the more traditional model of a library being stored in a set >>of files which contain all the necessary information (to generate >>executables) in a binary form. > > I'm not too sure what you mean here. The old/original way of handling > libraries in Ada (AFAIK) uses a kind of repository where packages are > added when they are compiled, and they have to be removed by hand. GNAT > changes the standard Ada way of handling libraries, by using normal link > libraries and a standard linker. I think I put this badly. What I mean is that gnatmake refers to source code files (specs) when working out which files to recompile (and in what order). This requires a certain amount of extra parsing that I want to avoid. I also want to totally disconnect source files from the library rebuilding process, apart from those source files which are being explicitly submitted, so as not to impose avoidable limitations on the way source text files are stored (compressed, encrypted, on a different machine, privileged, etc.). >>I want ECLAT to be able to target the AdaOS native executable format for >>the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is >>suitable (only) for a 'flat' memory model, and I think adapting it to >>generate code that supports the NEAI/IA-32 segmented architecture would >>be difficult. > > No offence, but your OS is not going to be too portable in the near > future. AdaOS has been carefully designed so that all code will be 100% portable (at the source code level), barring hardware differences (and segmentation is surely a hardware difference). Support for segmentation will be totally implicit in normal Ada code (general access values will be segmented, pool-specific ones will not), so that porting normal code to another hardware platform will only require recompilation. If the hardware does not support segmentation, the compiler will emit code which uses the flat memory model. Only a small amount of the overall AdaOS source code will be hardware-dependent. > Segmentation is being done away with in the 64-bit x86 CPU's > AFAIR. Some CPU's don't support it at all (PPC). In fact both the 32-bit and 64-bit PowerPC architectures are segmented, and I intend to make full use of this. The way segmentation works on this architecture is different to the 'traditional' model used by the IA-32. All segments have the same size, each has a fixed location in the linear address space, and they are contiguous. This has the advantage that the addressing model can be linear or segmented. > Either way, it would be possible to provide a flat-memory model ECLAT > under GCC, via a front-end port. There are distinct advantages to using a segmented model. It allows you to move blocks of data around in your linear address space, and resize them, without changing the machine code address of any of the data. This provides many benefits: dynamic stack and heap creation and resizing; easy and efficient shared module management; it helps with my IPC model. All these techniques are made necessary by the fact that the 32-bit linear space is becoming too small nowadays. The much bigger address space offered by 64-bit addressing solves the same problems in a different way. -- Nick Roberts ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-10-09 0:12 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-07 9:39 Ada memory management? matthias_k 2004-10-07 12:06 ` Martin Krischik 2004-10-07 17:24 ` Nick Roberts 2004-10-07 19:04 ` Luke A. Guest 2004-10-07 22:52 ` ECLAT [was: Ada memory management?] Nick Roberts 2004-10-08 18:16 ` Luke A. Guest 2004-10-09 0:12 ` Nick Roberts
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox