In C, how do you know if the dynamic allocation succeeded?

Should the question be like this? "Can a program ~~allocate~~ use more memory than is physically available on the server (assuming no swap)?" Because, malloc allocates from virtual memory, not from the physical memory. Only when we access the the memory explicitly by read/write for the first time, then the page fault happens and page allocation begins. If page can't be allocated, then program gets terminated with a SIGNAL. Here, malloc was successful since allocation from VM was successful. But that is no guarantee that we have all memory we got. We can still run out of memory even though we allocated everything at start of program... It is so un predictable ... So, I assume, your question is asked with above intention. Please correct me if I am wrong. Your question and whole thread made me to think! -p

If you care, you mmap it, and request MAP_POPULATE.

It would not be very surprising if, once enough people come to depend on this, they break that, too.

> At work we have microservices crashing 20 times a week but SLOs are not affected since traffic is routed to surviving pods.

This probably makes a lot of people have strong negative emotions, but at the same time i feel that you're not wrong and it's the only way to deal with the modern web dev, where clients/business push for features instead of quality, versus something like kernel/system software development, where there is more pushback against this for historial and cultural reasons.

At work, we have this one monolith system that's in the center of everything else within a particular project - it's not really scalable and it has multiple scheduled processes within it, as well as serves a lot of external API requests, oh and also has an administrative UI. So far, my attempts to warn people against having a single point of failure like this have fallen on deaf ears and we still have outages where the JVM misbehaves or scheduled processes gobble up all of the server's memory and GC slows everything down on a regular basis.

Contrast this to me finally getting to implement something more like microservices in another project - the services are containerized and run on servers that have been configured with Ansible, are horizontally scalable and have proper load balancing. Furthermore, the scheduled process functionality and others can sit behind feature flags and be enabled within a particular instance, all while not having multiple separate projects and keeping things simple with a single, modular codebase. I actually dubbed this approach "moduliths", horizontally scalable and modular monoliths, since there is no way that this org can handle "proper" microservices, about which i wrote more here: https://blog.kronis.dev/articles/modulith-because-we-need-to...

That said, even the older monolith projects can benefit from modern approaches like Ansible for configuration management (which also prevents situations where environment configuration diverges over time and no one has any idea why) as well as being put into containers - the horrible monolith application now also lives within a container (not yet in prod, sadly) and has built in health checks. Were it ever to break and fail to recover in a set time, then it will automatically restart, making an outage that lasts an hour and possibly makes someone get paged in the middle of the night instead be a minute long interruption before everything restarts.

Personally, i think that with the direction that the industry is headed all services and even servers should be restarted every now and then anyways, since with JVM/CLR you sometimes get weird things happening after a service being up for months or years. Knowing why that happens would be nice, of course, but no one actually has the time to address those.

> Knowing why that happens would be nice, of course, but no one actually has the time to address those.

More than likely bad user code. Perhaps even race conditions. But in case of the JVM, with flight recorder and other forms of logging you could find out the problem with quite a good chance.

Which version of the JVM do you use?

Code quality is not neglected to the point we have logical errors. Architecture is reasonable and we have an extensive suite of end to end tests and integration tests.