www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5219] New: noheap annotation

reply d-bugmail puremagic.com writes:
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: -------
Nov 15 2010
next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 19 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 19 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5219


Dicebot <m.strashun gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m.strashun gmail.com


--- Comment #10 from Dicebot <m.strashun gmail.com> 2013-02-20 04:35:14 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 20 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5219


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com


--- Comment #11 from monarchdodra gmail.com 2013-02-20 05:35:12 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 20 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5219



--- Comment #12 from Rob T <alanb ucora.com> 2013-02-20 09:06:59 PST ---
(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 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 20 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5219



--- Comment #13 from bearophile_hugs eml.cc 2013-02-20 09:42:39 PST ---
(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/blrglebkzhrilxkbprgh forum.dlang.org 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{}. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 20 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5219


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg gmail.com


--- Comment #14 from Denis Shelomovskij <verylonglogin.reg gmail.com>
2013-06-30 16:56:38 MSD ---
One of the good usages of ` noheap` is a class destructor:
---
~this()  noheap; //  noheap for the win!
---

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