Allow imagefs files to be applications
Jeffrey Lee (213) 6046 posts |
Which is why I’m encouraging people to write better code, instead of sticking their heads in the sand and going “LA LA LA LA LA LA LA”. |
nemo (145) 2437 posts |
Again, time machine required. I don’t think it’s widely understood how bad the RMA is. This is an older version of RO5, but I doubt there’ll be much difference. This is within two minutes of booting: |
Rick Murray (539) 13413 posts |
Certainly – that’s why I say any new RMA must not stick code and data together. However, as you mention, that’s only a partial solution as the multitude of tiny allocations risk having the same sort of fragmentation issue, only somewhere else.
It might be worth wondering if a new RMA should run in SYS mode to try to begin a move away from third party stuff running the same as kernel level code.
But, as the High Vectors issue demonstrated – there’s an obvious problem when it comes to software that has been released, and the author subsequently left the scene. You know, when I first came here (what, 2011? 2012? back when my hair had colour…) the list of names writing to these forums is different to the names I see today. Martin Bazley and Trevor Johnson (didn’t he pop up earlier this year?) come to mind. As for software, how many times have people tried to find “x” to end up pinning their hopes on archive.org? Some people move on and do other things. |
Rick Murray (539) 13413 posts |
nemo, would you consider releasing your RMA tool? I’d be interested in looking at my machine. And… what the hell leaves a hole of that size in the RMA? What was it, 2717K? Can you peek at it, see if it looks like a JPEG or sprite or something? All those empty spaces – isn’t the RMA supposed to recycle empty parts if new claims fit? |
nemo (145) 2437 posts |
The problem with the “it’ll get reused” theory is that it doesn’t account for the gross difference in allocation sizes, which was never intended to be this bad. That RO5 “WimpPool” is ridiculous. It ought to be in its own DA.
WimpPool. I’m not even going to look at it, it’s so clearly insane. I am not an advocate for RO4, and I was certainly never a supporter of ROL (quite the opposite), but their decision to move some things out of the RMA into their own DAs was clearly the right thing to do. Fragmentation occurs far less on RO4 even after days of uptime. The RO5 RMA above is immediately after booting. ROL got some of the address space reservations comically wrong (16MB of ‘Filer workspace’?!), but things like the Wimp sprites should certainly not be in the RMA – huge monolithic blocks and microscopic node soup do not mix well. (And look at the address space % usage here… ridiculous1) The node soup is mostly FontManager, DisplayManager, MimeMap and, on RO5, Toolbox. But tiny allocations (although indicative of inefficient memory management) aren’t the problem. It’s huge allocations which are liable to grow, and the mixing of mission-critical data with user buffers. It’s an old problem (witness the MessageTrans vulnerabilities that persisted for years) and it’s evidently difficult to get programmers to understand the repercussions of the difference between pull and push interfaces, user-supplied buffers and shared buffers, etc, but part of the solution is to provide a choice of locales for data, buffers, and exposed tables. I’ve espoused the ‘high RMA’ idea, and I would agree that it ought to be read-only from USR mode. Hence the requirement for a module flag to enable it and new OS_Module reasons to allocate from it. There are modules that write into their own body instead of allocating storage, and there are APIs where the user-mode program may be writing into whatever buffer has been returned by the module – even if that is within its own body. It may be ‘icky’ but it’s not illegal. One must always assume that if code could have done something, somewhere there is code that has done it. You can abandon such code if you’re engineering a closed system like a set-top-box. You can’t if you’re maintaining a desktop OS with a thirty-two-year back catalogue. 1 Address space starvation: The single best solution of the aversion to DAs and their problem of address space starvation is to introduce movable DAs – that is, DAs that the OS can shift if it needs to resize another. One flag, and a couple of reason codes for the handler and problem solved. |
nemo (145) 2437 posts |
Some time ago I said I’d release ModuleUtils 0.04 (23 Oct 2019) © nemo 2019 ZapMsg 0.24 (06 Nov 2002) © Tim Tyler DrawBasicFs 1.10 (9th Dec 1992) !Utils So there’s a real in-the-wild example of what has only ever been an informational field, and why I’m having to be so careful about making it machine-readable. By contrast, I’ve been having fun with these: XModChina 0.01 (108年 12月 31日) © nemo 2019 XModISO8601 0.01 (2019-11-08) © nemo 2019 XModJapan 0.01 (2019年 11月 08日) © nemo 2019 XModJapanEra 0.01 (令和1年 11月 08日) © nemo 2019 XModKorea 0.01 (2019년 11월 08일) © nemo 2019 |