SoylentNews is people
SoylentNews
from the constants-aren't-variables-won't dept.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA:
VLAs [(Varable Length Arrays)] allow for array lengths to be determined at run-time rather than compile time. The Linux kernel has long relied upon VLAs in different parts of the kernel -- including within structures -- but going on for months now (and years if counting the kernel Clang'ing efforts) has been to remove the usage of variable-length arrays within the kernel. The problems with them are:
- Using variable-length arrays can add some minor run-time overhead to the code due to needing to determine the size of the array at run-time.
- VLAs within structures is not supported by the LLVM Clang compiler and thus an issue for those wanting to build the kernel outside of GCC, Clang only supports the C99-style VLAs.
- Arguably most importantly is there can be security implications from VLAs around the kernel's stack usage.
[...] Kees Cook[*] sent out the pull request today for VLA removal that now enables the "-Wvla" compiler flag to emit a warning should any variable-length array be found within the kernel's C code. That will help prevent new code from inadvertently using VLAs and also spot any lingering kernel code still relying upon this behavior.
Kees Cook wrote that there still might be a few places where VLAs could be found, "there may be a couple more VLAs hiding in hard-to-find randconfigs, but nothing big has shaken out in the last month or so in linux-next. We should be basically VLA-free now! Wheee. :)"
[*] KeesCook.
Have you ever used VLAs? Removed them? Why?
(Score: 3, Informative) by Immerman on Monday October 29 2018, @05:06PM
The functionality would be pretty much the same, but the I suspect the in-memory structures would be very different, which can have profound performance implications in some situations. (I'm not actually familiar with using VLAs, but given their syntax and the language rules I only see one obvious candidate)
The key factor is that
int x;
int vla_array[size];
int z;
Guarantees that the contents of vla_array lie in the immediately vicinity of x and z, dramatically increasing the chances that they'll all be loaded into processor cache at the same time after not having been accessed recently.
Whereas
int x;
int *heap_array = malloc(..size..);
int z;
Means that the contents of heap_array are located at an effectively random location in memory. Which means that once all the data has left the cache, and then you say "....the_array[7]...."; You trigger a cache-miss to load the pointer "heap_array" and then, once that's fully loaded, immediately trigger *another* cache-miss to load the contents of the array. And triggering a cache-miss is one of the most performance-killing things you can do. Depending on expected access patterns, the difference can have a devastating effect on performance.
There's also a smaller but more persistent performance penalty in that
vla_array[3] translates to "dereference(3 + offset_to_vla_array + stack_pointer )"
heap_array[3] translates to "dereference( 3 + dereference(stack_pointer + offset_to_heap_array_pointer)) "
with the performance cost of dereferencing being dependent on hardware, compiler, and code characteristics.
And as alluded above me - allocating and deallocating memory on the stack is essentially free, while doing so on the heap can incur a substantial penalty - both in immediate costs and in memory fragmentation.
There's also situations where in-place arrays would be just as bad for performance - the key is to understand what you're actually asking of the computer so that you can use the right tool for the job.