On Thursday, 25 November 2021 at 02:32:41 UTC, max haughton wrote:
> the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.

I am not quite sure what you are saying.  Are you saying that:

1. The problem is moving the allocation somewhere other than the gc, including potentially to the stack, or to an alternate heap, or to somewhere else; or,

2. Converting allocations from gc to the stack is fine; but moving them anywhere else is problematic

In either case, this compiles currently and produces GC-free code:

@nogc:
void f(scope int[] x);
void g(int x, int y) { f([x, y]); }

I'm not sure where you would want to move scope allocations to aside from the stack, as scope guarantees LIFO, and so is the perfect fit for a stack.  Perhaps an alternate stack (cf 'brk') managed in druntime, to avoid stack overflow?  That would be good, but is hardly a challenging transformation if you can already produce regular stack allocation.

On Thursday, 25 November 2021 at 09:29:49 UTC, Elronnd wrote:
> On Thursday, 25 November 2021 at 02:32:41 UTC, max haughton wrote:
>> the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.
>
> I am not quite sure what you are saying.  Are you saying that:
>
> 1. The problem is moving the allocation somewhere other than the gc, including potentially to the stack, or to an alternate heap, or to somewhere else; or,
>
> 2. Converting allocations from gc to the stack is fine; but moving them anywhere else is problematic
>
> In either case, this compiles currently and produces GC-free code:
>
> @nogc:
> void f(scope int[] x);
> void g(int x, int y) { f([x, y]); }
>
> I'm not sure where you would want to move scope allocations to aside from the stack, as scope guarantees LIFO, and so is the perfect fit for a stack.  Perhaps an alternate stack (cf 'brk') managed in druntime, to avoid stack overflow?  That would be good, but is hardly a challenging transformation if you can already produce regular stack allocation.

Just use malloc and free. If you want to be clever stick a branch in there or forward to a tuned allocator. The fact that the stack is LIFO makes absolutely no difference compared to the cost of calling into the GC and even worse potentially causing a collection.

On Thursday, 25 November 2021 at 09:29:49 UTC, Elronnd wrote:
> On Thursday, 25 November 2021 at 02:32:41 UTC, max haughton wrote:
>> the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.
>
> I am not quite sure what you are saying.  Are you saying that:
>
> 1. The problem is moving the allocation somewhere other than the gc, including potentially to the stack, or to an alternate heap, or to somewhere else; or,
>
> 2. Converting allocations from gc to the stack is fine; but moving them anywhere else is problematic
>
> In either case, this compiles currently and produces GC-free code:
>
> @nogc:
> void f(scope int[] x);
> void g(int x, int y) { f([x, y]); }
>
> I'm not sure where you would want to move scope allocations to aside from the stack, as scope guarantees LIFO, and so is the perfect fit for a stack.  Perhaps an alternate stack (cf 'brk') managed in druntime, to avoid stack overflow?  That would be good, but is hardly a challenging transformation if you can already produce regular stack allocation.

Moving an unbounded allocation to malloc and free is fine. LIFO is totally irrelevant.

The point is avoiding putting pressure on the GC. If you want to be clever you can probably come up with some hybrid arrangement that tries to use the stack if it can or has a buffer somewhere.

On Thursday, 25 November 2021 at 15:42:28 UTC, max haughton wrote:
> Moving an unbounded allocation to malloc and free is fine. LIFO is totally irrelevant.
>
> The point is avoiding putting pressure on the GC. If you want to be clever you can probably come up with some hybrid arrangement that tries to use the stack if it can or has a buffer somewhere.

LIFO is a useful property that you can take advantage of.  Why would you _want_ to allocate on the heap when you could allocate on [some kind of] stack?

Re GC pressure, you get the same amount of pressure (amortized, assuming bounded allocation size and call-stack depth) if you allocate with the gc and then GC.free at the end of the scope.

On Thursday, 25 November 2021 at 20:41:07 UTC, Elronnd wrote:
> On Thursday, 25 November 2021 at 15:42:28 UTC, max haughton wrote:
>> Moving an unbounded allocation to malloc and free is fine. LIFO is totally irrelevant.
>>
>> The point is avoiding putting pressure on the GC. If you want to be clever you can probably come up with some hybrid arrangement that tries to use the stack if it can or has a buffer somewhere.
>
> LIFO is a useful property that you can take advantage of.  Why would you _want_ to allocate on the heap when you could allocate on [some kind of] stack?
>
> Re GC pressure, you get the same amount of pressure (amortized, assuming bounded allocation size and call-stack depth) if you allocate with the gc and then GC.free at the end of the scope.

Because it's overly complicated. You can have a parallel stack if you want but KISS.

The GC could collect at the first allocation. The point is to avoid the GC entirely, more of a latency thing than throughput. Assuming the analysis is reliable in the frontend this also allows the function to be @nogc without forcing the programmer to do the memory allocation themselves.