Summary: Built-in trait to tell functions that allocate from
                    the GC heap
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD

--- Comment #0 from 2011-11-08 16:01:52 PST ---
Here Don presents the idea of a dedicated GC for pure functions:

This is a part of the first post:

> (Note that the compiler can determine if a function makes any 
> memory allocations, simply by inspecting its body -- it isn't any more 
> difficult than checking if it is nothrow).

Once this idea is implemented, it's very easy to offer it to D programmers too.

So as step to implement Don's GC idea I think it will be useful a
__traits(gcallocates, someFunction) that returns true at compile-time if
someFunction performs allocations from the GC heap. This trait is transitive,
so to return true all the functions called by someFunction need to not perform
GC activity, even if they are in other modules (but the lack of GC allocations
is not a function attribute includes in function signatures as @noheap of bug
5219, so maybe in some situations this feature has to be conservative an err on
the side of safety).

- - - - - - - - - - - -

Knowing that a function is GC-free is quite useful in certain situations.

If you write:

int foo(in int x) {
static assert(__traits(gcallocates, foo));

It's likes writing:

@noheap int foo(in int x) {

The main differences are that @noheap is part of the signature of foo.

- - - - - - - - - - - -

Adding an annotation like this, where somehighLevelFunction is a function
that's the root of a big part of a program allows to be sure the big part
doesn't use the GC:

static assert(__traits(gcallocates, somehighLevelFunction));

The whole program is GC-free:

static assert(__traits(gcallocates, main));

To use this well, I think __traits(gcallocates,...) has to return good error
messages, like a stack trace, that shows that functions (or the first found
function) of the tree of functions called by someFunction are not GC-free.

- - - - - - - - - - - -

A comment by Gor Gyolchanyan:

> , because it would allow to specialize
> functions based on the way, let's say, delegates behave and if they
> don't use GC, the specialized function would also restrain from using
> it making it follow the behavior pattern and making it much more
> usable in performance-critical environments, while keeping it usable
> in GC-aware environment too.

- - - - - - - - - - - -

See also:
bug 5219 (@noheap annotation)
bug 5070 (Heap-allocated closures listing)

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to