Re: Lazy and GC Allocations
On Monday, 20 February 2023 at 19:58:32 UTC, Steven Schveighoffer wrote: On 2/20/23 1:50 PM, Etienne wrote: On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote: See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't? The opposite, the delegate doesn't force a closure, and so when the variable goes out of scope, memory corruption ensues. I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently It shouldn't. Now, lazy can't be `@nogc` (because that's just what the compiler dictates), but it won't actually *use* the GC if you don't allocate in the function call. I just tested and you can use lazy parameters with betterC. -Steve The @nogc issue might be what might be why it didn't work for me. I use it because it's easier to work with betterC but perhaps I should avoid writing @nogc code altogether Thanks for the info! Etienne
Re: Lazy and GC Allocations
On 2/20/23 1:50 PM, Etienne wrote: On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote: See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't? The opposite, the delegate doesn't force a closure, and so when the variable goes out of scope, memory corruption ensues. I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently It shouldn't. Now, lazy can't be `@nogc` (because that's just what the compiler dictates), but it won't actually *use* the GC if you don't allocate in the function call. I just tested and you can use lazy parameters with betterC. -Steve
Re: Lazy and GC Allocations
On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote: See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 -Steve So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't? I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently Etienne
Re: Lazy and GC Allocations
On 2/19/23 9:15 PM, Steven Schveighoffer wrote: Indeed, you can't really "save" the hidden delegate somewhere, so the calling function knows that the delgate can't escape. I stand corrected, you can save it (by taking the address of it). And it's explicitly allowed by the spec. But it still doesn't allocate a closure! See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 -Steve
Re: Lazy and GC Allocations
On 2/19/23 7:50 PM, Etienne wrote:
Hello,
I'm wondering at which moment the following would make an allocation of
the scope variables on the GC. Should I assume that the second parameter
of enforce being lazy, we would get a delegate/literal that saves the
current scope on the GC even if it's not needed? I'm asking purely for a
performance perspective of avoiding GC allocations.
```
void main() {
int a = 5;
enforce(true, format("a: %d", a));
}
```
enforce takes a lazy variable, which I believe is scope by default, so
no closure should be allocated.
Indeed, you can't really "save" the hidden delegate somewhere, so the
calling function knows that the delgate can't escape.
-Steve
Lazy and GC Allocations
Hello,
I'm wondering at which moment the following would make an
allocation of the scope variables on the GC. Should I assume that
the second parameter of enforce being lazy, we would get a
delegate/literal that saves the current scope on the GC even if
it's not needed? I'm asking purely for a performance perspective
of avoiding GC allocations.
```
void main() {
int a = 5;
enforce(true, format("a: %d", a));
}
```
Thanks
Etienne
