Writing Garbage Collector in C

References:

Support:

Feel free to use this video to make highlights and upload them to YouTube (also please put the link to this channel in the description)

[InmuAyuayu]

This guy: writes Garbage Collector in C
Me: writes Garbage in C

[Gabriel_Pureliani]

Your garbage collector doesn't work, i'm still here

[OdyseeEnjoyer]

I've a lot of experience with C and padding (specially with bitfields) but your way of teaching is so interesting that you've made me to stay for the entirety of the video

[Valo_iO]

wasted 5 years in uni, studying CS (I failed some unrelated classes, that's why it took me that long), and I learned more by watching your videos and similar things on YT!

[playerguy]

14:11 you are mostly correct.
essentially, the compiler is guaranteeing alignment of the datatypes involved.
Most machines have memory alignment requirements for most datatypes.

On x86_64:

Chars cannot have one nybble in one address and the other in another address.
Shorts must be aligned to 2 bytes.
Ints must be aligned to 4 bytes.
etc, etc..
Same applies to (hardware-)vector datatypes. (look up vectorized instructions for more info.)

So you have rightly observed that chars have a smaller alignment requirement than the pointer, and as such can be packed more effectively.

Printing the addresses would've confirmed that.

If that behavior is not desirable (for example, if you'd rather pack data as densely as possible) you can use the pack pragma in C/C++.
The downside is more costly reads and writes.

[LuisMatos_ahoy]

"I am a random person from the internet allowing you to use global variables!"
Nice 😂😂

[tresuvesdobles]

Pretty cool video! BTW: If there is a cycle of pointers among several chunks in the heap (it may not necessarily be a two-cycle) your code will enter a never-ending loop until you reach recursion limit and cause a Stack Overflow. A naive solution would be to set a manual recursion limit on mark_region, but then cyclic chunks would never be deallocated.

[heraldo]

You should mark as alive only the heap chunks that can be reached from the stack. It will make self-referenced chunks to be collected too (circular pointers). If you take the heap itself as root of the "references tree" circular refs will stay alive forerer, thus leading to memory leaks.

[nivelis]

After watching this I immediately hate this channel for how many videos you have, how long they are, and that I'm not gonna be able to see them all in one weekend.

[freestyle]

I think you can don’t use builtin gcc function for get the frame address. Just declare on the stack some variable of type uintptr_t and get pointer to it by the “&” operator.

[DatBoi_TheGudBIAS]

The stack is always aligned to 8 bytes, actually to 16 most of the time
The reason is Dat it requires 16 byte alignment for faster access for mnemonics such as movaps, Cuz movups, the unaligned version, is slower and less optimized
Many functions internally use movaps and other aligned instructions so the stack is automatically aligned either before the call or on startup (I'm not sure where)
But it always is

[adamkrawczyk]

15:06, just bookmarking but good shit. It's pretty interesting

[xirate]

45:55 there's some Terry Davis energy here

[berndeckenfels]

I debugged the traditional GC of gofer (Haskell variant) on DOS because it did not use pointers but “cell index” which way too often tainted memory for integer value (with only a few hundred cells available that hurt very much).

[greob]

That was really interesting, thanks for sharing.

[siddharthsinghchauhan]

Although his sessions are not educational per se... But damn they are awesome... I watched this particular one many times.. to figure stuff out for design interviews

[liebranca]

sizeof(size_t) != sizeof(intptr_t), though generally it doesn't matter c:
Cool stuff btw. Subscribed.

[cheebadigga]

I think the struct Foo is 16 bytes instead of 9 because of how GCC does structs. It has a special "packed" mechanic for structs which prevents it from aligning to the full next 8 bytes, but only if you're explicit about it (GCC extension to the C standard). Maybe clang would've behaved differently. Maybe not. But either way, it's the compiler who does the alignment, not the kernel or libc.

Tried it out: typedef struct { char i; void *ptr; } __attribute__((packed)) FooPacked;

results in 9 bytes instead of 16.

So essentially as long as you're on x86_64 GCC you can be 99% certain that the alignment is done for you by GCC if you're not explicitly tell it to do otherwise. I don't know about other architectures so I can't say anything about them.

[aFlyingElefant]

In what video did you develop your arena allocator? I cannot find any reference to it in the faq or the repo or anything.

[berndeckenfels]

With struct #pragma pack applies - but that does not apply to the location of data segments