[HN Gopher] Static Allocation for Compilers
       ___________________________________________________________________
        
       Static Allocation for Compilers
        
       Author : enz
       Score  : 16 points
       Date   : 2025-12-23 22:53 UTC (6 days ago)
        
 (HTM) web link (matklad.github.io)
 (TXT) w3m dump (matklad.github.io)
        
       | delifue wrote:
       | How does static allocation avoid wasting memory?
       | 
       | Static memory allocation requires hardcoding an upper limit of
       | size of everything. For example, if you limit each string to be
       | at most 256 bytes, then a string with only 10 bytes will waste
       | 246 bytes of memory.
       | 
       | If you limit string length to 32 bytes it will waste fewer memory
       | but when a string longer than 32 bytes comes it cannot handle.
        
         | Joker_vD wrote:
         | > if you limit each string to be at most 256 bytes, then a
         | string with only 10 bytes will waste 246 bytes of memory.
         | 
         | No? Unless you limit each string to be _exactly_ 256 bytes but
         | that 's silly.
         | 
         | > If you limit string length to 32 bytes it will waste fewer
         | memory but when a string longer than 32 bytes comes it cannot
         | handle.
         | 
         | Not necessarily. The early compilers/linkers routinely did
         | "only the first 6/8 letters of an identifier are meaningful"
         | schtick: the rest was simply discarded.
        
         | AlotOfReading wrote:
         | Your C++ compiler already implements a solution to that called
         | short string optimization. Strings start out as small byte
         | buffers that can be easily be passed around. When they grow
         | beyond that, the fixed buffer is swapped out for pointer to
         | another allocation on the heap. There's no (immediate) reason
         | that allocation has to come from a direct call to the system
         | allocator though, and it usually doesn't. It can just as easily
         | come from an allocation pool that was initialized at startup.
         | 
         | Even if you needed to hardcode upper size limits, which your
         | compiler already does to some extent (the C/C++ standards
         | anticipate this by setting minimum limits for certain things
         | like string length), you wouldn't actually pay the full price
         | on most systems because of overcommit. There are other
         | downsides to this depending on implementation details like how
         | you reclaim memory and spawn compiler processes, so I'm not
         | suggesting it as a good idea. It's just possible.
        
       | Joker_vD wrote:
       | Yes, you can dump your IR straight to the disk and then stream it
       | to process further. That's how quite a number of compilers (and
       | assemblers) were written back in the 70s and it was quite
       | painful.
       | 
       | IIRC, Unix's original as works that way: during assembly, the
       | text and data sections are written into separate temporary files,
       | and then they are merged together into the a.out. And yes, it's
       | slow.
        
       | cloudhead wrote:
       | How does this work? Files need to reference other files eg. for
       | calling functions from other modules, which means semantic
       | analysis needs both files in memory to check the types. This is
       | especially complicated with mutual recursion across modules
       | (separate compilation doesn't apply here). If you're building a
       | language like C where everything requires forward declarations,
       | then maybe, but anything more modern seems difficult.
        
       | pwdisswordfishy wrote:
       | > I feel that a strict separation between O(N) compiler output
       | and O(1) intermediate processing artifacts [...]
       | 
       | I don't follow. He has just said that although the size of the
       | arena is finite, the input and output are unbounded, and the
       | compiler does its work by processing "a sequence of chunks" (i.e.
       | those things that will fit into the finitely sized arena). That's
       | not "O(1) intermediate processing artifacts". It's still O(n).
       | 
       | > [...] can clarify compiler's architecture, and I won't be too
       | surprised if O(1) processing in compilers would lead to simpler
       | code
       | 
       | This doesn't seem like an intuitive conclusion at all. There's
       | more recordkeeping needed now, and more machinery in need of
       | being implemented, and one should expect that this scheme would
       | make for things that are neither simple nor easy.
       | 
       | We haven't even gotten around to addressing how "statically
       | allocating" a fixed size arena that your program necessarily
       | subdivides into pieces (before moving onto the next chunk and
       | doing the same) is just "dynamic allocation with extra steps".
       | (If you want or just think that it would be neat to write/control
       | your own allocator, then fine, but... say that.)
        
         | pwdisswordfishy wrote:
         | Having said that, if this is really all just a roundabout way
         | to get the Rust people to actually give a damn about memory use
         | and sell the idea that "you _really_ shouldn 't require more
         | than 4GB of memory just to bootstrap the compiler and/or build
         | other medium-to-very-large programs," then hey that's great.
        
       ___________________________________________________________________
       (page generated 2025-12-29 23:00 UTC)