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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021