www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Lazy and GC Allocations

reply Etienne <etcimon gmail.com> writes:
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
Feb 19 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Feb 19 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Feb 19 2023
parent reply Etienne <etcimon gmail.com> writes:
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
Feb 20 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Feb 20 2023
parent Etienne <etcimon gmail.com> writes:
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
Feb 20 2023