Hi Alexander,
our discussion intermingles two topics that should better stay separated.
(A) How to overcome the road block of the Go runtime depending on an mmap feature, which is not available on Genode?
(B) What happens when a component runs out of memory?
Here I see some contradiction - in our (and most, probably) cases we write child process and software, not parent. I even don’t know who my parent in that case. In normal Unix/Wndows/etc I know that this could be some kind of aux processes provided to me by OS on which I don’t have any power. So, may be it worth to have a separation between «own intentional distributed inside OS (like genode) or over net application childs» and single application as a child of extenrally (not mine!) provided parent?
I'm sorry about the confusion. I should have been more specific. Does my reply to Cedric [1] clarify that question?
[1] https://lists.genode.org/pipermail/users/2019-September/006902.html
And, my hard believe that any application can’t «just hangs» in any case. At least, in production environment. Even for research/educational ones - I can’t understand why, if I configure system wrongly, it just demonstrate black screen, without any reasonable way to find a reason (can’t attach debugger - not supported on my configuration, and I even don’t know the stack of hanging application/rom module/etc, as it happens with me).
I agree. I think you got me wrong. I did not want to suggest infinite blocking as an acceptable general solution. But in the static part of the system (the part spawned by the first init instance), resources _are_ statically partitioned. If those static boundaries are violated by one component, the static system ensures that unrelated components are not affected. But it won't magically make the misbehaving component work.
Since there is no general answer to the question of what should happen when a component behaves unexpectedly, the Genode base system does not even try to implement a policy. Instead, it offers a mechanism - the dynamically configurable init I described in my reply to Cedric - that allows you to implement a policy you see fit best.
I get stuck for some time, now I found some ways, like ask to reserve only 1 gb of ram and try to run everything here, it is somehow supported for mipsle platform. Now I am stuck again in the setting up of signal processing… All these requires efforts in trying to fix runtime code doing some nasty things before even main program. The next potential problem I expect in stack switching (used by go coroutines), and, may be in stack growth (temporary I disable common gcc mechanism from morestack.c). Hope to have soon running helloworld application from go.
You spent most of your email discussing topic (B). It's good that you raised the issue, so that Cedric could jump on it, and I had a chance to promote Genode's approach.
However, in the context of your pressing problem at hand (A) and the other nasty technicalities you mentioned above, the discussion of (B) is a distraction, isn't it? It does not help you progressing with (A).
That said, I don't have any magic spell for overcoming (A) unfortunately. Intuitively, I'd try to change the memory-allocation backend of the runtime, just like I stated in my previous posting. But since I haven't looked into the Go runtime myself, I unable to substantiate that.
Cheers Norman