www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - assert(false) and GC

reply DLearner <bmqazwsx123 gmail.com> writes:
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
Jul 08
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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
Jul 08
prev sibling next sibling parent russhy <russhy gmail.com> writes:
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
Jul 09
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/8/21 11:11 AM, DLearner wrote:
 Hi
=20
 Please confirm that:
 `
  =C2=A0=C2=A0 assert(false, __FUNCTION__ ~ "This is an error message");=
 `
=20
 Will _not_ trigger GC issues, as the text is entirely known at compile =
 time.
=20
 Best regards
One way of forcing compile-time evaluation in D is to define an enum=20 (which means "manifest constant" in that use). I used nogc to prove=20 that there is no GC allocation as well: nogc void main() { enum msg =3D __FUNCTION__ ~ "This is an error message"; assert(false, msg); } Ali
Jul 09
parent reply russhy <russhy gmail.com> writes:
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
Jul 09
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jul 09
parent reply russhy <russhy gmail.com> writes:
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
Jul 09
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Jul 09
parent reply russhy <russhy gmail.com> writes:
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
Jul 09
parent reply Mathias LANG <geod24 gmail.com> writes:
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.
Jul 10
next sibling parent russhy <russhy gmail.com> writes:
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
Jul 10
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Jul 11