4 ms·

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t reall

• syncsynchalt 6y ago
  In my experience dynamic allocation is banned in either (a) small embedded environments or (b) high scrutiny environments (soft realtime, safety critical, etc). In both cases the project size is small enough, or the scrutiny is high enough that the ad-hoc allocator doesn't develop. The environment is also simple enough that the memory cheats you're thinking of don't exist (or you can squash them by touching all allocated memory up front).
• rightbyte 6y ago
  > How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? You could maybe call filescope buffers with an size counter a dynamic memory allocation. I.e. for storing RS232 or CAN messages. Since they shrink and grow. The important thing is that you want to know that flooding one buffer wont flood another, which malloc could result in if it was used for unrelated buffers.
• xxpor 6y ago
  It's an embedded system, it's very likely there's no OS in the first place.
  • lmilcin 6y ago
    Actually it is irrelevant whether you use an operating system or not. One project I worked with these rules was on Verix OS. The rules are more intended on reducing application complexity and unpredictability which is typically helping reliability regardless of the setting.
    • xxpor 6y ago
      It was mostly on if the OS would actually allocate physical memory, or if it'd do a linux style overcommit. Without an OS, the latter is very unlikely.
      • lmilcin 6y ago
        Again, Linux DOES NOT overcommit memory. Linux does not lie about what available memory is. Rather, it is most developers that do not understand how memory is managed on Linux. What you probably mean is that you don't get physical memory when you run malloc(). That's because when you allocate memory on Linux you allocate virtual address space rather than physical memory. Basically, you get a bunch of addresses that may or may not be backed up by physical pages. If you want physical memory you just need to use mlock() along with malloc() and you are all fine.
        • xxpor 6y ago
          You're redefining overcommit from how everyone else uses it. https://www.kernel.org/doc/Documentation/vm/overcommit-accounting https://www.kernel.org/doc/Documentation/vm/overcommit-accou...
          • lmilcin 6y ago
            If you want to "allocate" (reserve) physical memory just call malloc and then mlock. No lie. You get physical pages or error. Get over it. What you call "allocation" is two distinct operations on Linux, one of which is called malloc in standard c library, unfortunately, and that's where your confusion comes from.
            • surajrmal 6y ago
              Overcommitting means providing more virtual memory to be mapped than is available in physical memory. It works by mapping memory as readonly, mapped to a zero page, and "committing" a real physical page when a write occurs to a page for the first time. The act of asking for virtual memory and mapping it is considered allocation. Linux overcommits virtual memory. Some OS, like Windows, actually commit physical pages to back virtual memory when you ask try to map new virtual memory. I think you know these things and it's mostly just a semantics argument, but this is the widely agreed definition.
• lmilcin 6y ago
  Why would you want to implement your own allocator? The goal of these rules is to improve reliability and timeliness of your application. If you intend on working around those rules to do what the rules explicitly forbid then either you or the rules are wrong.
  • closeparen 6y ago
    Suppose your problem intrinsically has variable numbers of variable size records coming and going at runtime. Sure you can allocate a big array upfront. But it seems to me that the code which directs records to slots in this array is an allocator.
• wongarsu 6y ago
  > Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use. That depends on the OS. Linux lies (overcommits), Windows doesn't. In embedded it's more typical to have a special OS like VxWorks or FreeRTOS that don't lie to you, or to have no OS at all (like basically every arduino project)
  • lmilcin 6y ago
    Linux doesn't lie, it is just probably not doing what your simplified view of memory allocation is. On Linux memory allocation is basically assigning range of address that may or may not be backed by pages in physical memory. This allows doing a lot of interesting and useful stuff. If you really want the memory for some reason (for example you need to guarantee your operation finishes without running out of memory), you need to touch the pages or force them in some other way (for example using mlock()). It is just that developers are mostly oblivious how memory management works on Linux and then are surprised that it doesn't exactly do what they want. Most people I work with can't tell how much memory is available on a Linux box if their life depended on it.
    • remexre 6y ago
      On my machine, which to my knowledge hasn't had this setting changed, ulimit -l reports each process can only lock 64KiB of memory... I feel like "you should use mlock()" isn't really practical advice.