Liste des Groupes | Revenir à cl c |
On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:Yes, but garbage collectors that could be useable for C, C++, or other efficient compiled languages are not "copying" garbage collectors.On 06/03/2024 23:00, Michael S wrote:Copying garbage collectors literally stop fragmentation.On Wed, 6 Mar 2024 12:28:59 +0000Garbage collection does not stop heap fragmentation. GC does, I
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.
>
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).
ReachableI 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.
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.
Les messages affichés proviennent d'usenet.