Re: assert(false) and GC
On 7/10/21 12:32 PM, Mathias LANG wrote: On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote: On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. i think you are right Try to use `@nogc` instead, it'll show you it does not allocate. A caveat though: A failing assert used to allocate before v2.097.0 (the latest version), it does not anymore. However, as your test captures all GC allocation, it likely triggers while the runtime is initializing. No, because if you remove the assert, and just include the override of gc functions, nothing triggers. I can't remember which release, but the runtime has been changed to not use the GC until the application needs it. The assert is triggering the GC, either on the throw or the catch (i.e. printing out the stack trace). I tend to think the latter, but hard to prove with this simple test. If you want to know where it is, just debug it and break in the GC allocation function. -Steve
Re: assert(false) and GC
On Saturday, 10 July 2021 at 16:32:30 UTC, Mathias LANG wrote: On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote: On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right Try to use `@nogc` instead, it'll show you it does not allocate. A caveat though: A failing assert used to allocate before v2.097.0 (the latest version), it does not anymore. However, as your test captures all GC allocation, it likely triggers while the runtime is initializing. yes you are right, i forgot to add extern(C) in main, so the allocation happens in the runtime initialization and not for the assert i apologies for the confusion i caused
Re: assert(false) and GC
On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote: On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right Try to use `@nogc` instead, it'll show you it does not allocate. A caveat though: A failing assert used to allocate before v2.097.0 (the latest version), it does not anymore. However, as your test captures all GC allocation, it likely triggers while the runtime is initializing.
Re: assert(false) and GC
On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: On 7/9/21 8:44 PM, russhy wrote: On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote: On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to >> define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one > liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). https://run.dlang.io/is/HJVSo0 it allocates That test is possibly showing the wrong thing. You are capturing all allocations, not just the concatenation. Change the assert line to: ```d string s = __FUNCTION__ ~ "This is an error message"; ``` And no GC allocations occur. Even without optimizations turned on. I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right
Re: assert(false) and GC
On 7/9/21 8:44 PM, russhy wrote: On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote: On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). https://run.dlang.io/is/HJVSo0 it allocates That test is possibly showing the wrong thing. You are capturing all allocations, not just the concatenation. Change the assert line to: ```d string s = __FUNCTION__ ~ "This is an error message"; ``` And no GC allocations occur. Even without optimizations turned on. I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve
Re: assert(false) and GC
On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote: On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). Ali https://run.dlang.io/is/HJVSo0 it allocates
Re: assert(false) and GC
On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). Ali
Re: assert(false) and GC
On Friday, 9 July 2021 at 22:53:10 UTC, Ali Çehreli wrote:
On 7/8/21 11:11 AM, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at
compile time.
Best regards
One way of forcing compile-time evaluation in D is to define an
enum (which means "manifest constant" in that use). I used
@nogc to prove that there is no GC allocation as well:
@nogc
void main() {
enum msg = __FUNCTION__ ~ "This is an error message";
assert(false, msg);
}
Ali
this is very bad, assert are good because they are one liner,
making it 2 line to avoid GC is just poor design, compiler should
be smarter
Re: assert(false) and GC
On 7/8/21 11:11 AM, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at compile
time.
Best regards
One way of forcing compile-time evaluation in D is to define an enum
(which means "manifest constant" in that use). I used @nogc to prove
that there is no GC allocation as well:
@nogc
void main() {
enum msg = __FUNCTION__ ~ "This is an error message";
assert(false, msg);
}
Ali
Re: assert(false) and GC
i think it only allocate when it hit the assert, but program will halt so it's not big deal, even though i feel this is a stupid design to make everything depend on GC... it gives bad impression when you want avoid it here is how i do to detect hidden GC allocations https://run.dlang.io/is/HJVSo0 if you attach a debugged you can see exactly where is the culprit
Re: assert(false) and GC
On Thursday, 8 July 2021 at 18:11:50 UTC, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at
compile time.
Best regards
Consider below. Only z will generate an error. This is called
string literal concatenation, which comes from C [1].
```d
@nogc void main() {
string x = __FUNCTION__ ~ "This is an error message";
string y = "This is an error message";
string z = __FUNCTION__ ~ y;
}
```
[1]
https://en.wikipedia.org/wiki/String_literal#String_literal_concatenation
assert(false) and GC
Hi Please confirm that: ` assert(false, __FUNCTION__ ~ "This is an error message"); ` Will _not_ trigger GC issues, as the text is entirely known at compile time. Best regards
