digitalmars.D.bugs - [Issue 5219] New: noheap annotation
- d-bugmail puremagic.com (23/23) Nov 15 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (11/11) Nov 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (8/8) Nov 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (11/11) Nov 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (50/52) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (32/32) Nov 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (14/14) Nov 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (14/19) Nov 20 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (24/29) Feb 19 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (12/14) Feb 19 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (16/16) Feb 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (16/16) Feb 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (12/21) Feb 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (18/20) Feb 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
- d-bugmail puremagic.com (13/13) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5219
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
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
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=5219
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugdbug yahoo.com.au
No.
Use a profiler.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5219 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
http://d.puremagic.com/issues/show_bug.cgi?id=5219
nfxjfg gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nfxjfg gmail.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=5219 12:40:40 PST ---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
http://d.puremagic.com/issues/show_bug.cgi?id=5219
SHOO <zan77137 nifty.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zan77137 nifty.com
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=5219 14:24:31 PST ---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.both nogc and noheap are very usefullWell, 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
http://d.puremagic.com/issues/show_bug.cgi?id=5219
Rob T <alanb ucora.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alanb ucora.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=5219We 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
http://d.puremagic.com/issues/show_bug.cgi?id=5219
Dicebot <m.strashun gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m.strashun gmail.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=5219
monarchdodra gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra gmail.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=5219More 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
http://d.puremagic.com/issues/show_bug.cgi?id=5219More 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
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
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