July 10, 2021

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

July 11, 2021

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

1 2
Next ›   Last »