On Monday, 28 June 2021 at 01:18:57 UTC, Elronnd wrote:

You think more than 4K for a stack frame is very large? That is a crazy and unworkable restriction. Even when 2K is enough for a single function it will be a complete disaster as inlining could make this 16K in a heartbeat.

The stack is the correct place to put fast allocations as that memory is in the cache.

Well, D is not a system level language, that is for sure.

On Sunday, 27 June 2021 at 22:16:12 UTC, IGotD- wrote:

No, because the compiler can refuse to inline, but it is a bad idea.

It also means that safe functions cannot call FFI, how can you prove that FFI does not exceed 4K after inlining?

D is trying to become a high level language, but is also aiming to be system level and that is not really an attainable goal. You have to make a choice. It would be better for D to not go for 100% safe, but instead prevent common mistakes.

I've never ran out of stack for any code I've written ever.

Maybe that means allocating larger stacks so that guard pages are never hit, add more guard pages and simply terminate when guard pages are hit.

Other alternatives: do stack depth analysis, add stack less coroutines.

Anyway, for a system level language, those choices should be at the hand of the programmer. I agree with you on that.

On Monday, 28 June 2021 at 07:10:05 UTC, Ola Fosheim Grøstad wrote:

I'm pretty worried how this would affect the actual coroutines/fibers implementation. I'm slowly trying to write a retro game engine that uses a lot of fibers (hundreds!) on a single thread.

On Monday, 28 June 2021 at 07:27:46 UTC, Luis wrote:

Did you mean the proposed 4K limitation? Your project sounds like a fun project! I started programming on a CBM64 8-bit computer with hardware sprites… ;-). Seems like your project could be a use case for stackless coroutines. I was quite surprised to see that embedded programmers also care a lot about stackless coroutines as they can implement state machines with predictable memory consumption. There is also a presentation on youtube that explains how database search optimizations can make good use of them to speed up parallell binary searches in indexes. Also surprising to me. Seems to be a lot of room for innovation in the concurrency design space.

On Monday, 28 June 2021 at 07:10:05 UTC, Ola Fosheim Grøstad wrote:

Hitting guard pages and you will get an exception and a core dump. That's one way to do it but there is no explicit message that you ran out of stack. By checking the stack limit for each frame you can gracefully exit and print a message. Any of these methods gives you a performance hit and I am a bit skeptical that it is worth it. I think it should be an opt in feature.

This kind of feature is similar to Visual Studio C/C++ debug mode which has extensive stack analysis for each frame. The performance hit very high for branchy code but I have discovered a lot of bugs the debug stack analysis. VS also put in guard patterns between stack variables so that you can detect if there is any overwrite within a frame. These kind of bugs are common in C/C++, mainly because there is no bounds checking with arrays.

I don't like limits on how I use the stack and if the programmer is an amateur is a weak argument. I really question how effective this limit is. I rather go the VS route which mean proper stack analysis in debug mode.

On Monday, 28 June 2021 at 08:54:59 UTC, IGotD- wrote:

You should be able to trap it and use the program counter/stack pointer to figure out where it happened. Then you can extend the stack if you are able to, if not call a cleanup handler.

The best thing is obviously to prove that the stack usage will stay within a worst case estimate. That is what you want in embedded and comparable applications. That should obviously be opt in, as it prevents arbitrary recursion, but then you also need no guards and other complications.

The «amateur» claim is 100% bogus and a made up excuse. There is nothing wrong with stack allocating buffers near the leafs on the callstack. When you know what the call depth is then allocating temporary buffers on the stack is a good, high performing strategy if the runtime and code-gen is sensible.

If you specify what your estimated worst case stack depth is, then you shouldn't hit the guard pages anyway. For a system level language the programmer should decide this, absolutely!

On Monday, 28 June 2021 at 09:17:46 UTC, Ola Fosheim Grøstad wrote:

Isn't this what D is doing now, anyway?

On Monday, 28 June 2021 at 07:10:05 UTC, Ola Fosheim Grøstad wrote:

Slightly related, but I was recently learning how to implement coroutines myself and it was crashing because MSCV's printf allocates a rather large buffer on the stack. Can't remember the exact size, but I'm pretty sure it was at least 4K.

So in other words, you can't prove it for foreign functions I believe.