Garbage collection in D

bearophile bearophileHUGS at lycos.com
Thu Jun 4 02:43:08 PDT 2009


Frits van Bommel:
> LDC actually still does a dynamic allocation there because it doesn't eliminate 
> dynamic allocations in loops.

I have compiled the loop in foo() with LDC:

class AllocationItem {
    int value;
    this(int v) { this.value = v; }
}
int foo(int iters) {
    int sum = 0;
    for (int i = 0; i < iters; ++i) {
        scope auto item = new AllocationItem(i);
        sum += item.value;
    }
    return sum;
}

The asm of the core of the loop:

.LBB2_2:
    movl    $_D11gc_test2b_d14AllocationItem6__vtblZ, 8(%esp)
    movl    $0, 12(%esp)
    movl    %edi, 16(%esp)
    movl    %ebx, (%esp)
    call    _d_callfinalizer
    incl    %edi
    cmpl    %esi, %edi
    jne .LBB2_2

I can see a call to finalizer, but not the allocation?


> This is unfortunate, but I haven't yet had the time to figure out how to get the 
> optimization passes to prove the allocation can't be live when reached again. 
> (If multiple instances of memory allocated at the same allocation site may be 
> reachable at the same time, it's not safe to use a stack allocation instead of a 
> heap allocation)

The new JavaVM with the option I have shown is clearly able to do such things.
Can't you take a look at the source code of the JavaVM? :-)
There's a huge amount of NIH in the open source :-)

Bye,
bearophile


More information about the Digitalmars-d-learn mailing list