On Monday, 23 November 2020 at 03:27:48 UTC, RazvanN wrote:
> I've been looking into this and the main issue that has caused slow progress in templatizing the runtime is the fact that the hooks need to be `@trusted pure @nogc nothrow`. Why? Because those hooks may get called from `@trusted pure @nogc nothrow`

@trusted I understand, but the others should be correctly inferred be a template anyway and if they can't be.... so be it. There are already druntime functions you can't use from @nogc, they're just special cased in the compiler instead picked up from the implementation...

On Monday, 23 November 2020 at 03:44:02 UTC, Adam D. Ruppe wrote:
> On Monday, 23 November 2020 at 03:27:48 UTC, RazvanN wrote:
>> I've been looking into this and the main issue that has caused slow progress in templatizing the runtime is the fact that the hooks need to be `@trusted pure @nogc nothrow`. Why? Because those hooks may get called from `@trusted pure @nogc nothrow`
>
> @trusted I understand, but the others should be correctly inferred be a template anyway and if they can't be.... so be it. There are already druntime functions you can't use from @nogc, they're just special cased in the compiler instead picked up from the implementation...

What about purity? If your code is pure but the runtime hook is not? And then there are many functions like this in druntime:

void checkSomething(T)(T a) @trusted nothrow @nogc
{
    /* some other checks */
    assert(a != fun(), "Fail");
    /* some other checks */
}

Let's say this function is used everywhere in druntime. You cannot mark it as pure because the compiler will then optimize it away and if you need it you just have to duplicate the code. Also if you want to format the message of the assert, normally you would use `~` however, you want your function to be @nogc so then you have to use the existing crippled AssertFormat in druntime which may not be enough for your needs.

My point is that you have to work around a lot of hindrances to implement this.

On Monday, 23 November 2020 at 03:53:04 UTC, RazvanN wrote:
> And then there are many functions like this in druntime:

Do you have a specific example in there now? Your little given example uses assert and would thus be compiled out anyway of the normal druntime build.

> Also if you want to format the message of the assert, normally you would use `~` however, you want your function to be @nogc

With the `debug` keyword you can do stuff like this. Of course only sometimes compiled in so not necessarily helpful to druntime but maybe.

On Monday, 23 November 2020 at 04:04:44 UTC, Adam D. Ruppe wrote:
> On Monday, 23 November 2020 at 03:53:04 UTC, RazvanN wrote:
>> And then there are many functions like this in druntime:
>
> Do you have a specific example in there now? Your little given example uses assert and would thus be compiled out anyway of the normal druntime build.
>

Hmmm, I struggled with this in https://github.com/dlang/druntime/pull/3267 .
I did not know that asserts are ignored in normal builds. So typically you
would need to manually throw an Error in cases like checking array bounds.

>> Also if you want to format the message of the assert, normally you would use `~` however, you want your function to be @nogc
>
> With the `debug` keyword you can do stuff like this. Of course only sometimes compiled in so not necessarily helpful to druntime but maybe.

On Sunday, 22 November 2020 at 20:49:19 UTC, random wrote:
> On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:
>> One of the things I mentioned is that I don't get why library solutions are pursued for handling memory allocations/garbage collecting when the runtime already exists and can be used for the same purpose.
>
> A benefit of the library solution is that the user can always create their own
> implementation when needed.
> You can write your own malloc in C, which is useful if you want to program an os... (for example)
>

Actually no, you cannot not, at least not with pure ISO C.

Allocating from a global static buffer yes, but for something like a proper malloc() taking from a OS wide memory pool, either inline Assembly, external Assembly or compiler intrisics are required to interface with the memory management hardware.

If we are talking about GCC C, clang C, MSVC, TI C, aCC, xlC,... then yeah C can do it.

This is one of my trick questions, how to implement malloc() in ISO C on bare metal.

On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:
> On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:
>> So that means there are only three options left: single threaded GC pool, non-language GC or ARC.
>
> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>
> We are only missing Windows support for a partially concurrent GC atm.
>
> This is the direction I believe our default should be. It covers pretty much all use cases with reasonable performance.

Fork is expensive in the sense that when the game modifies memory the process has to halt while the OS creates a copy of that memory page.

You have to be very careful when writing applications that call fork, you don't want two processes appending to the same file etc.

It a very special cased soltuion that basically won't work with existing c++ codebases without vetting...

More suitable for a high level language where the compiler can set up the application for fork.

On Monday, 23 November 2020 at 08:17:30 UTC, Ola Fosheim Grostad wrote:
> You have to be very careful when writing applications that call fork, you don't want two processes appending to the same file etc.

I guess this is not an issue with POSIX fork in this context as it only keeps the thread that called fork. But there can be issues related to resources.

On Monday, 23 November 2020 at 08:58:43 UTC, Ola Fosheim Grostad wrote:
> On Monday, 23 November 2020 at 08:17:30 UTC, Ola Fosheim Grostad wrote:
>> You have to be very careful when writing applications that call fork, you don't want two processes appending to the same file etc.
>
> I guess this is not an issue with POSIX fork in this context as it only keeps the thread that called fork. But there can be issues related to resources.

For instance, if the app marks memory as dontfork with madvise and the gc traces a pointer into that memory.

On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:
> On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:
>> So that means there are only three options left: single threaded GC pool, non-language GC or ARC.
>
> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>

> ...
>
> This is the direction I believe our default should be. It covers pretty much all use cases with reasonable performance.

Can you expand on this?

On Sunday, 22 November 2020 at 20:20:50 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:
>> But yeah, this all comes down to the fact that the runtime really needs work these days. And to a degree, I imagine user-provided templates that dictate how code should be generated is an interesting compiler design paradigm that can help there.
>
> If you want to mix ARC and GC in the same executable, for high efficiency, you need at least two types of pointers: owning and nonowning, and to break cycles you also need weak pointers (turns to null on destruction) which are useful for speculative caching as well.
>
> The good news is that going from ARC to GC is free and that ARC annotated pointers will collect faster with a precise tracing GC than is the case today. So clearly a win for libraries, either way.
>
> The bad news is that doing ARC in the LLVM IR is nontrivial so you may need a new intermediary typed language specific IR. But you need that to do @live well anyway... So, why not?

Other bad news is that if you don't want the runtime to look bad against tracing GC implementations,

https://github.com/ixy-languages/ixy-languages

You need to ship your own CPU with ARC specific improvments,

https://blog.metaobject.com/2020/11/m1-memory-and-performance.html