http://d.puremagic.com/issues/show_bug.cgi?id=5219

           Summary: @noheap annotation
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-11-15 13:44:26 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2010-11-17 04:50:46 PST ---
No.
Use a profiler.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219



--- Comment #2 from bearophile_hugs@eml.cc 2010-11-17 15:55:19 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg@gmail.com


--- Comment #3 from nfxjfg@gmail.com 2010-11-17 21:59:28 PST ---
It's certainly a good idea for a systems programming language. But I don't know what the hell D2 wants to be.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219



--- Comment #4 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-18 12:40:40 PST ---
(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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219


SHOO <zan77137@nifty.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zan77137@nifty.com


--- Comment #5 from SHOO <zan77137@nifty.com> 2010-11-19 07:17:10 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219


Michal Minich <michal.minich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michal.minich@gmail.com


--- Comment #6 from Michal Minich <michal.minich@gmail.com> 2010-11-19 15:39:03 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219



--- Comment #7 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-20 14:24:31 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219


Rob T <alanb@ucora.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alanb@ucora.com


--- Comment #8 from Rob T <alanb@ucora.com> 2013-02-19 17:43:24 PST ---
(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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5219



--- Comment #9 from bearophile_hugs@eml.cc 2013-02-19 18:42:48 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------