Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: "White House to Developers: Using C or C++ Invites Cybersecurity
 Risks"
Date: Fri, 8 Mar 2024 15:32:22 +0100
Organization: A noiseless patient Spider
Lines: 103
Message-ID: <usf7hn$1o7fd$1@dont-email.me>
References: <us0brl$246bf$1@dont-email.me> <us1lb5$2f4n4$1@dont-email.me>
 <us2lfh$2ltj3$5@dont-email.me> <us2s96$2n6h3$6@dont-email.me>
 <us3155$2of1i$3@dont-email.me> <us4c66$346tp$3@dont-email.me>
 <us5d6f$3besu$3@dont-email.me> <20240305005948.00002697@yahoo.com>
 <us5u16$3eidj$2@dont-email.me> <20240305111103.00003081@yahoo.com>
 <us8821$90p$4@dont-email.me> <20240306140214.0000449c@yahoo.com>
 <us9nib$dski$1@dont-email.me> <20240307000008.00003544@yahoo.com>
 <usc58s$10cls$1@dont-email.me> <20240307083119.850@kylheku.com>
 <useegp$1ihfv$1@dont-email.me> <20240308125746.000074c1@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 8 Mar 2024 14:32:23 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5b4fd483861029d4eca5978ecaa265e3";
	logging-data="1842669"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/MEImCX21lSO3vdAwUZY17YYg1QbxPHwk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:XYaOS2UqhrIYTD5v4bG1+4PdM4w=
In-Reply-To: <20240308125746.000074c1@yahoo.com>
Content-Language: en-GB
Bytes: 6345

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.
>