Bug 5219 – @noheap annotation

In D often heap allocations are the main cause of low performance code, or they may cause less deterministic code (in video games, etc). A function annotation named "@noheap" may help (similar to @nothrow), it makes sure a function/method contains no heap allocations (new of arrays/objects/structs, array concat, array append, closures, associative array insertions, malloc/realloc/calloc, and so on, but not alloca()) and doesn't call other things that perform heap allocations.

No. Use a profiler.

This problem may be solved by a better profiler, or by an alternative to the switch suggested in bug 5070 If this idea is bad then it may be closed.

It's certainly a good idea for a systems programming language. But I don't know what the hell D2 wants to be.

(In reply to comment #1) > No. > Use a profiler. I compiled this code with profiler --- class A { int delegate() a; } A f() { int a=1; int g() { a+=3; return a; } A b=new A(); b.a=&g; a+=2; return b; } int main() { assert(f().a()==6); return 0; } --- It gave me this output: ------------------ 1 __Dmain _D4test1fFZC4test1A 1 7801 7801 ------------------ 1 __Dmain _D4test1fFZC4test1A1gMFZi 1 16 16 ------------------ __Dmain 0 9139 1322 1 _D4test1fFZC4test1A 1 _D4test1fFZC4test1A1gMFZi ======== Timer Is 2000320000 Ticks/Sec, Times are in Microsecs ======== Num Tree Func Per Calls Time Time Call 1 3 3 3 _D4test1fFZC4test1A 1 4 0 0 __Dmain 1 0 0 0 _D4test1fFZC4test1A1gMFZi --- How can I tell whether the code calls heap allocation functions?

I agree this suggestion. This is not only performance but also behavior. When GC runs, it is a very huge cause of trouble to lack in real-time processing. All programs may not work under the abundant resources. There are software that put emphasis on point that should work in limited resource and limited duration like embedded software. There are software that cannot offer performance to be satisfied with if they don't control it by a high-speed period of 1,000Hz like haptic device controlling. There are software to control the medical device that the delay of moment takes the human life. It is fatal to lack in this property. Of course it will be impossible to encode not to use GC at all. In that case, you may move processing to another thread that never use GC. It is not important that a heap is assigned, and it is important that GC does not work. Therefore I prefer "@nogc" to @noheap. On the other hand, there is a problem of the readability. It does not appear on the code even if I introduced a profile to observe a behavior of the real-time processing. The property is clear if @nogc/@noheap is given to the attribute of the function. It is the best that the thing which wants not to be compiled is not compiled. And I think it to be the information that a compiler can grasp like nothrow.

both @nogc and @noheap are very usefull, and I would like to have them available. @nogc being less strict - allowing for manual memory management. I think that both these attributes should be processed by some other tool. Performance considerations are not usually part of the language, but are common as third party solutions.

(In reply to comment #5) > This is not only performance but also behavior. Multithreading, GC and TLS have global consequences, who knows, how third-party code will react on it. We know, how TLS is broken in dlls on windows and how some system calls spawn threads unexpected by druntime, which leads to crashes. (In reply to comment #6) > both @nogc and @noheap are very usefull Well, attribute may be an overkill, compiler switch is enough (module-wide switch). > I think that both these attributes should be processed by some other tool. > Performance considerations are not usually part of the language, but are common > as third party solutions. Other tool can't know, when compiler decides to alloc, especially a third-party tool. This can even depend on compiler switches like optimization.

(In reply to comment #7) > Well, attribute may be an overkill, compiler switch is enough (module-wide > switch). We definitely need to mark localized sections of code to be off limits from the GC. This is because for many applications, only certain sections of code have a problem with the GC, while the remaining non-critical sections have no need to suffer without a GC. I do agree though that some code will have to be 100% GC disabled, so some means to prevent application wide use of garbage collected reliant code would be useful. > > Other tool can't know, when compiler decides to alloc, especially a third-party > tool. This can even depend on compiler switches like optimization. The 3rd party tool idea makes little sense to me. This is not just an optimization issue, it's a safety issue and a productivity issue. If the compiler can tell me I'm using GC collected sections of code in error, that's many times better than it not telling me anything at all, and leaving it up to me to figure out where I may be going wrong. As it is right now, disabling the GC is a very unsafe business because it's far too easy to use something that does hidden allocations. --rt

(In reply to comment #8) > We definitely need to mark localized sections of code to be off limits from the > GC. The point of annotations like @nogc or @noheap is to denote and disable specific kinds of side effects. In a language that tries to be efficient and safe it's quite useful to have a precise control on what side effects a piece of code has. On the other hand D was not designed for such precise control from the beginning, so such annotations are handled not so well, they require some work to be used, the inference of kinds of side effects is not refined, etc.

Vote up, both this and @nogc. For my embedded experiments I was considering doing a stub version of gc that asserts on every allocation attempts, but more complex projects may still want to use gc for some high-level resource management and being able to cleanly mark the code that is supposed to be free from allocations will help a lot. It makes no sense as a compiler switch or an external tool as this is deeply tied to language semantics and will naturally prohibit usage of plenty of D features that do hidden allocations.

More than just annotating "no GC" or "no Heap", what would be nice is being able to mark any sections with the same qualifiers as functions. For example, for certain types of touchy cleanup, it would *tremendously* help being able to have a "nothrow" section, which means "while my function can legally throw an exception, I need this specific section to not throw anything, and I need the compiler to enforce this for me". Ditto for "@safe". And, why not, const.

(In reply to comment #11) > More than just annotating "no GC" or "no Heap", what would be nice is being > able to mark any sections with the same qualifiers as functions. > > For example, for certain types of touchy cleanup, it would *tremendously* help > being able to have a "nothrow" section, which means "while my function can > legally throw an exception, I need this specific section to not throw anything, > and I need the compiler to enforce this for me". > > Ditto for "@safe". And, why not, const. Yes I agree. This has been brought up before with respect to @trusted since it makes a lot of sense to be able to mark @trusted sections of unsafe code in a @safe function. I have no idea why this was not done by design from the start because it seems too obvious to have been missed. Are there issues with the idea that we don't know about? --rt

(In reply to comment #11) > More than just annotating "no GC" or "no Heap", what would be nice is being > able to mark any sections with the same qualifiers as functions. This is an interesting idea, but it's essentially orthogonal to the idea of a @noheap. There was already a discussion about introducing @trusted{...}. So generalizing that idea to all of them isn't a big leap. But it's stuff for a different enhancement request: - - - - - - - - Code section support for @trusted, @safe, pure, nothrow In this thread David Nadlinger has suggested a @trusted" declaration/block: http://forum.dlang.org/thread/[email protected] if that feature will be introduced, then maybe it's worth introducing a generalization of it, supporting the block syntax for @trusted{}, @safe{}, pure{}, nothrow{}.pure{}, nothrow{}.

One of the good usages of `@noheap` is a class destructor: --- ~this() @noheap; // @noheap for the win! ---

See the start of the development of @nogc here: https://github.com/D-Programming-Language/dmd/pull/3455

This issue has 11 votes, but after this comment by Ola Fosheim G.: > Btw, I think you should add @noalloc also which prevents both new and malloc. > It would be useful for real time callbacks, interrupt handlers etc. Walter has started a sub-thread answering: > Not practical. malloc() is only one way of allocating memory - > user defined custom allocators are commonplace. So I presume @noheap has very little hope, and currently the best chance to have something similar is @nogc. So unless you want to rename this issue "@nogc annotation", I think it should be closed down.