Memory should be free
@lunarised Wanted a chunk of memory anyway? We already had that, it was called static arrays.
Seriously, since a couple years I wonder if one can always replace malloc/free with forks.
I think that it should be possible to prove that you always bind memory to processing, and there is no other reason except programmer lazyness to do such processing in the same process.
Counter-argument: sed hold-space processing.
Counter-counter-argument: you just need more expressive pipes and redirections, and instead of one single hold-space, you'd get multiple spaces each connected to simpler version of sed.
Counter-counter-counter argument: that's cheating, as the pipes would handle memory growth under the hood in kernel space.
But... why not?
Userspace programs would be way simpler (and safer) without malloc/free.
Performance: does it really matter when people use editors like vscode?
More interesting question: what you would do to improve performance in such system?
As for mmap: there is no mmap. 😉
@Shamar @lunarised
design new CPU architecture where modifying TLB is cheap
That would improve performance wherther you allowed user-space malloc/free or not.
Can't we think anything for such specific os design?
@Shamar @lunarised ok, how about this: fork creates 1000 processes at once. If userspace needs fewer, it should suballocate them somehow.
@Shamar @lunarised vscode doesn't use malloc, it uses a GC.
A gc that use malloc to acquire more memory.
But the point is that the amount of code run by vscode, shows that performance doesn't matter much.
I mean: an editor coded in javascript and run on a browser.
@Shamar @lunarised in some usecases, performance doesn't matter much.
In other usecases, performance does matter, but the incentives are such that the developers don't care and the user is forced to endure unreasonable wait times, or buy a better computer.
In other cases performance is critical.
I know a person who writes hand-optimized assembly in current year, because in their field it makes sense to do it.
For example graphical applications need a buffer to contain the whole pixel array, this need to be dynamic.
@lanodan @Shamar @lunarised one process per pixel ftw
@lanodan @Shamar @lunarised racing the beam like it's Atari VCS
- Windows tends to be resizeable
- Displays do not all have the same pixel density
- Displays do not all have the same size
Only case where you could consider using static memory would be for loading slashes and error popups.
Pixel density and size of a display can be known in advance.
Windows' max size is that of the (virtual) display and actually, if you properly align your memory buffer, when the actual size is smaller then the available memory, several pages are never faulted.
@lanodan @wolf480pl @lunarised
(this is an honest question, I know near to nothing about low level graphics.. but I mean: you know how large is the screen, don't you?)
And runtime means malloc.
@Shamar @lanodan @lunarised you'd need to know it at compile time
Well, to be precise, you'd need to know it at loading time. In mainstream os this mean you must know it at compile time to save such info in your ELF binary or something.
But could we imagine something more flexible than that?
@Shamar @lunarised performance would be trash.
Also, whether it's a static array or malloc, in the end it's all mmap.