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
