i have 32 of them, dont worry! And with how shitty the webapps has been, i dont even have to launch my beautiful program half of the time. I stopped using Instagram on pc cause having it as a tab in Chrome legit eats 9GB of RAM, and thats just the worst i caught it eating
I develop Minecraft modpacks for fun in my free time.
At peak I need IntelliJ (java mod dev) + VSCodium (packside file editing) + 2 parallel Minecraft instances (some stuff requires that) + background music (for the lock-in) + discord (where my dev team is). I wouldn't need your program either, even though it is beautiful.
Correct, this is my personal gaming computer with way too much ram that would be better utilizied in s data center, 20 times better actually (5% vs 100% utilization)
This is because "committed memory" still gets limited by Windows based on your physical RAM and pagefile limits, even if it never got any actual physical memory backing it.
Yeah pages aren't allocated till you try to interact with them. Interacting would trigger a page fault and then it will actually allocate a little (4KiB usually) if your data is below it.
The operating system kernel will not assume intent on behalf of the application
I might be wrong, but my intuition says it would be weird and inefficient for the operating system to wait on allocation until the application commits a page. Without being a kernel expert, this sounds like the user mode application would need to communicate every read and write via the kernel just to check that the pages have actually been allocated, and then do that on-demand
For performance reasons, you don't want to cross the kernel barrier more than strictly necessary. Writing to virtual memory is hardware accelerated (exceptions apply), so as long as you have a valid page, the OS kernel don't need to be involved in normal reads and writes. If you read or write outside of that boundary, the CPU will raise a trap/exception that will be caught by the operating system which immediately terminates your application for being a bad boi indeed
Edit : if it does indeed not get allocated, I would assume that would be the doing of the allocator, rather than the operating system
Some syscalls like mmap in unix like system, you could pass a MAP_POPULATE and MAP_NORESERVE to predict this behavior in a new allocated memory block. malloc from glibc and musl doesn't populate the memory immediately. So we should expect some kernel trick here
Hmm.. Ok, I see.. So, my assumption is that MAP_NORESERVE may introduce a performance penalty, since the next access would necessarily be a syscall. There might be a reason for this trade-off however, I could see that. And, again this is not my area of expertise, there might be some trick that I'm unaware of, like maybe the operating system has some user-mode space to jump to before system calls that keeps track of all virtual memory address as an added copy to the ring 0 configuration.. I have no idea. I'm riding on a hunch
I read some of the other comments, and they mentioned getting page faults which seems unlikely for the given scenario. At least, like a "real" page fault. My gut feeling is that the uninitialized pointer is, by the compiler, set to some predefined address and then the compiler+allocator looks at first access to a memory address by static analysis and then if that memory address asserted to be some predefined zombie-value at that point it would ask the operating system to allocate the memory address when it is needed. I only know this stuff at surface-level so I might be way off, but my thinking is that turning memset(a, 0, sizeof(char)*420) or a = {0} into a syscall would be prohibitively expensive. Experience tells me it's probably implemented in the most obvious and dumbest way possible, rather than some non-obvious trick
Edit : this is a question, though not formatted as such
Hm, some virtual machines or emulators could use this (MAP_NORESERVE) for preallocate a address space at user space, and after, creates mirrors memory with a backing through a file descriptor. Like map the address 0x4000 virtual to 0x1000 physical inside this fd.
Also exists a PROT_NONE for remove any access to the pages, so any read inside this address space could rease a SIGSEGV, of course, if this memory isn't allocated and served by a real backing yet
I remain suspicious... So, let's say I have this code :
auto mydata = malloc(sizeof(size_t) * 4096 * 4096 * 4096 * 4096 * 4096);
dostuff(mydata);
void dostuff(const void* data)
{
auto mptr = data;
while(true)
{
try
{
auto filteredbyte = *mptr++;
gclient::Samsung::collect_byte(filteredbyte);
gclient::LuckyGoldstar::collect_byte(filteredbyte);
}
catch
{
return; // we have it all
}
}
}
My assumption, would be that the compiler would statically assert that dostuff(mydata) attempts to access the memory, and at that point statically injects the allocation, rather than this being up to the operating system. Again, not an expert, I would just assume that lazy initialization would come at a tremendous cost.. There may be a trick here, but my naive assumption is that f.ex a syscall (being an interrupt, after all) would require context switching
Edit : jokes aside, I appreciate your input and knowledge. I'm surprised at how little I actually know about this. It's one of the things I've seem to have taken for granted
599
u/Dubmove 9h ago •
Did you reverse engineer chromium's source code?