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

On 08/03/2024 11:57, Michael S wrote:

On Fri, 8 Mar 2024 08:25:13 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 07/03/2024 17:35, Kaz Kylheku wrote:

On 2024-03-07, 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).

>
Copying garbage collectors literally stop fragmentation.

>
Yes, but garbage collectors that could be useable for C, C++, or
other efficient compiled languages are not "copying" garbage
collectors.
>

 Go, C# and Java are all efficient compiled languages. For Go it was
actually a major goal.

C# and Java are, AFAIUI, managed languages - they are byte-compiled and run on a VM.  (JIT compilation to machine code can be used for acceleration, but that does not change the principles.)  I don't know about Go.

 

Reachable
objects are identified and moved to a memory partition where they
are now adjacent. The vacated memory partition is then efficiently
used to bump-allocate new objects.
  

>
I think if you have a system with enough memory that copying garbage
collection (or other kinds of heap compaction during GC) is a
reasonable option, then it's unlikely that heap fragmentation is a
big problem in the first place.  And you won't be running on a small
embedded system.
>

 You sound like arguing for sake of arguing.

I am just trying to be clear about things.  Different types of system, and different types of task, have different challenges and different solutions.  (This seems obvious, but people often think they have "the" solution to a particular issue.)  In particular, in small embedded systems with limited ram and no MMU, if you use dynamic memory of any kind, then heap fragmentation is a serious risk.  And a heap-compacting garbage collection will not mitigate that risk.
There are a lot of GC algorithms, each with their pros and cons, and the kind of languages and tasks for which they are suitable.  If you have a GC algorithm that works by copying all live data (then scraping everything left over), then heap compaction is a natural byproduct.
But I think it is rare that heap compaction is an appropriate goal in itself - it is a costly operation.  It invalidates all pointers, which means a lot of overhead and extra care in languages where pointers are likely to be cached in registers or local variables on the stack.  And it will be tough on the cache as everything has to be copied and moved. That pretty much rules it out for efficient compiled languages, at least for the majority of their objects, and leaves it in the domain of languages that can accept the performance hit.

Of course, heap fragmentation is relatively rare problem. But when you
process 100s of 1000s of requests of significantly varying sizes for
weeks without interruption then rare things happen with high
probability :(

There are all sorts of techniques usable to optimise such systems. Allocation pools for different sized blocks would be a typical strategy.

In case of this particular Discord service, they appear to
have a benefit of size of requests not varying significantly, so
absence of heap compaction is not a major defect.
BTW, I'd like to know if 3 years later they still have their Rust
solution running.