How do garbage collected languages even work? Like if you dont tell it to allocate memory and free it how the fuck does it know to use memory? Also, are these so called "memory safe" langs actually "memory safe"? How do I know that the garbage collector actually works? Its asking quite a lot of me to assume that every single potential use case of memory possible is covered and accounted for both at compile time and run time. If i sound retarded then feel free to correct me, im not a C elitist or anything like that but the concept of trusting a garbage collector to just work and make memory leaks never happen is just crazy to me, it gives me the same uneasy feeling I get when someone tells me to "just have faith in god"
> from roots, walk every reference> copy all reachable data to a new place> fix references> nuke old place
>>107595201God is going to collect you and >>>/trash/
>>107595201every object keeps a reference to another object it uses. An array for example might contain 128 objects, making it reference each. The array itself can in turn also be referenced, for example via a local reference in the currently executed function. Once the reference count of an object reaches 0, it is freed and all objects it referenced get dereferenced, allowing them to be freed too.Now if you have very complex reference chains, an object can have a high reference count, but it is only freed if nothing has a reference to it anymore, preventing any use after free bugs (mostly).However you can't just actually free() the memory of the object once the reference count reached 0, since that would fragment the heap a lot, which is very bad for performance and memory usage. A better way is to regularly schedule a garbage collection, which pauses the whole program, frees all objects with a reference count 0 all at once, so that you get nice big freed sequential heap blocks again.
The GC first makes a list of everything that sparks joyThen the GC holds each object in its handsIf the object is on the list of things that sparks joy, it is safeOtherwise it goes in the trash
>>107595263more like>maintain list of allocations >from roots, walk every reference>deallocate any list element not in the treebut it's more complicated because of the whole generational thing. Allocation and GC in Java and C# are highly optimized for large numbers of short-lived objects.
>>107595201What's the point of these questions? Google and wikipedia exists.
>>107595457I trust randoms on 4chan more than i trust google or wikipedia.
>>107595457usecase for search engines?
>>107595201Yes you can have memory leak in a GC application. It is easy to diagnose and fix though.Any language in 2025 without GC is just tranny.
>>107595201GC languages don't do away with memory allocation. It's the deallocation part that's algorithmically determined. Every single object has an interface to mark whatever it can reach.This is compared against everything ever allocated and the missing links can be removed.
>>107595201There's actually many different algorithms, see this: https://spin.atomicobject.com/visualizing-garbage-collection-algorithms/
