[Issue 5219] @noheap annotation
https://issues.dlang.org/show_bug.cgi?id=5219 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #16 from bearophile_h...@eml.cc --- 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. --
[Issue 5219] @noheap annotation
https://issues.dlang.org/show_bug.cgi?id=5219 --- Comment #15 from bearophile_h...@eml.cc --- See the start of the development of @nogc here: https://github.com/D-Programming-Language/dmd/pull/3455 --
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Denis Shelomovskij changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #14 from Denis Shelomovskij 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219
--- Comment #13 from bearophile_h...@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/blrglebkzhrilxkbp...@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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 --- Comment #12 from Rob T 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #11 from monarchdo...@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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Dicebot changed: What|Removed |Added CC||m.stras...@gmail.com --- Comment #10 from Dicebot 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 --- Comment #9 from bearophile_h...@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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Rob T changed: What|Removed |Added CC||al...@ucora.com --- Comment #8 from Rob T 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 --- Comment #7 from Sobirari Muhomori 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Michal Minich changed: What|Removed |Added CC||michal.min...@gmail.com --- Comment #6 from Michal Minich 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 SHOO changed: What|Removed |Added CC||zan77...@nifty.com --- Comment #5 from SHOO 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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219
--- Comment #4 from Sobirari Muhomori 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
_D4test1fFZC4test1A178017801
--
1__Dmain
_D4test1fFZC4test1A1gMFZi11616
--
__Dmain091391322
1_D4test1fFZC4test1A
1_D4test1fFZC4test1A1gMFZi
Timer Is 200032 Ticks/Sec, Times are in Microsecs
Num TreeFuncPer
CallsTimeTimeCall
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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #3 from nfx...@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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 --- Comment #2 from bearophile_h...@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: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 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: ---
