assert(false) and GC

assert(false) and GC
Jul 08, 2021 DLearner
Jul 08, 2021 jmh530
Jul 09, 2021 russhy
Jul 09, 2021 Ali Çehreli
Jul 09, 2021 russhy
Jul 09, 2021 Ali Çehreli
Jul 10, 2021 russhy
Jul 10, 2021 Steven Schveighoffer
Jul 10, 2021 russhy
Jul 10, 2021 Mathias LANG
Jul 10, 2021 russhy
Jul 11, 2021 Steven Schveighoffer

July 08, 2021

Posted by DLearner

Permalink

DLearner

Permalink

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

July 08, 2021

Re: assert(false) and GC

Posted by jmh530
in reply to DLearner

Permalink

jmh530

Posted in reply to DLearner

Permalink

On Thursday, 8 July 2021 at 18:11:50 UTC, DLearner wrote:

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].

@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

July 09, 2021

Re: assert(false) and GC

Posted by russhy
in reply to DLearner

Permalink

russhy

Posted in reply to DLearner

Permalink

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

July 09, 2021

Re: assert(false) and GC

Posted by Ali Çehreli
in reply to DLearner

Permalink

Ali Çehreli

Posted in reply to DLearner

Permalink

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

July 09, 2021

Re: assert(false) and GC

Posted by russhy
in reply to Ali Çehreli

Permalink

russhy

Posted in reply to Ali Çehreli

Permalink

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

July 09, 2021

Re: assert(false) and GC

Posted by Ali Çehreli
in reply to russhy

Permalink

Ali Çehreli

Posted in reply to russhy

Permalink

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

July 10, 2021

Re: assert(false) and GC

Posted by russhy
in reply to Ali Çehreli

Permalink

russhy

Posted in reply to Ali Çehreli

Permalink

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

July 09, 2021

Re: assert(false) and GC

Posted by Steven Schveighoffer
in reply to russhy

Permalink

Steven Schveighoffer

Posted in reply to russhy

Permalink

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:

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

July 10, 2021

Re: assert(false) and GC

Posted by russhy
in reply to Steven Schveighoffer

Permalink

russhy

Posted in reply to Steven Schveighoffer

Permalink

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:

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

July 10, 2021

Re: assert(false) and GC

Posted by Mathias LANG
in reply to russhy

Permalink

Mathias LANG

Posted in reply to russhy

Permalink

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.

Top | Forum index | About this forum

Forums