Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks"

On 07/03/2024 12:44, Michael S wrote:

On Thu, 7 Mar 2024 11:35:08 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 06/03/2024 23:00, Michael S wrote:

On Wed, 6 Mar 2024 12:28:59 +0000
bart <bc@freeuk.com> wrote:
  

>
"Rust uses a relatively unique memory management approach that
incorporates the idea of memory “ownership”. Basically, Rust keeps
track of who can read and write to memory. It knows when the
program is using memory and immediately frees the memory once it
is no longer needed. It enforces memory rules at compile time,
making it virtually impossible to have runtime memory bugs.⁴ You
do not need to manually keep track of memory. The compiler takes
care of it."
>
This suggests the language automatically takes care of this.

>
Takes care of what?
AFAIK, heap fragmentation is as bad problem in Rust as it is in
C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
GC-based languages like Java, C# or Go.
  

Garbage collection does not stop heap fragmentation.  GC does, I
suppose, mean that you need much more memory and bigger heaps in
proportion to the amount of memory you actually need in the program
at any given time, and having larger heaps reduces fragmentation (or
at least reduces the consequences of it).
>

 GC does not stop fragmentation, but it allow heap compaction to be
built-in part of environment.

No, GC alone does not do that.  But heap compaction is generally done as part of a GC cycle.
Heap compaction requires indirect pointers.  That is to say, if you have a struct "node" on your heap, your code does not use a "node *" pointer that points to it.  It has a "node_proxy *" pointer, and the "node_proxy" struct points to the actual node.  Heap compaction moves the real node in memory, and updates the proxy with the new real address, while the main program uses the same "node_proxy" address. (These proxies, or indirect pointers, do not move during heap compaction.)  And the main program needs to be careful to access the data via the proxy, and re-read the proxy after every heap compaction cycle.
This is not going to work well with a low-level and efficient language - the extra accesses can be a significant burden for a language like C and C++.  But it can be fine for VM-based high-level languages, where the overhead is lost in the noise, and where the VM knows when the heap compaction has run and it needs to re-read the proxies.

So, it turns heap fragmentation
from denial of service type of problem to mere slowdown, hopefully
insignificant slowdown.

For high-level VM based languages, that could be correct.  But low-level compiled and optimised languages are dependent on addresses remaining valid, so heap compaction is not an option.
(An OS on a "big" system with an MMU can move memory pages around and change the virtual to physical memory mapping to get more efficient use of hierarchical virtual memory or to free up contiguous large page areas.  That is transparent to the user application code.)

I don't say that heap compaction is impossible in other environments,
but it is much harder, esp. in environments where pointers are visible
to programmer. The famous David Wheeler's quote applies here at full
force.
Also when non-GC environments chooses to implement heap compaction they
suffer the same or bigger impact to real-time responsiveness as GC.

Agreed.

So, although I don't know it for sure, my impression is that generic
heap compaction extremely rarely implemented in performance-aware
non-GC environments.

I think that is likely.

Performance-neglecting non-GC environments, first and foremost CPython,
can, of course, have heap compaction, although my googling didn't give
me a definite answer whether it's done or not.
 

CPython does use garbage collection, as far as I know.