3 ms·

Couldn't this be solved with strategy hint flags if necessary? I don't understand why you'd have to do task switching in the first place. You can't mark point

Couldn't this be solved with strategy hint flags if necessary? I don't understand why you'd have to do task switching in the first place. You can't mark pointers as unused without locking/syncing because kernel can reallocate pointers in the middle of scanning, no? That's the only reason, isn't it? But in kernel you'd know about it and you could mark unused pointers in single, lock/synchronisation free pass, no? In other words you don't need to stop the world if you are in kernel space because you know about all reallocations that are happening?

dragontamer 5y ago
> Couldn't this be solved with strategy hint flags if necessary? How is that easier than just the programmer choosing a garbage-collecting library and/or language that works for their use cases? Ex: Javascript / V8 gets this GC from this blogpost. Java gets their 3 or 4 command-line configurable GCs. Go gets their own. Lispers use their Lisp-gc implementation. Etc. etc. Because each programming community has a particular workflow / paradigm that works for them, each specific garbage collector is explicitly designed for each language's quirks. For example: Lisp "cons" is practically a constant-sized garbage collector, possibly implemented using bitsets because all car/cdrs are of a consistent size. Java is throughput focused by default, because of a large number of server-based customers. And of course: this Javascript / V8 focuses on latency optimization for the best UI responsiveness. > I don't understand why you'd have to do task switching in the first place. Wrong word. I meant system call. Either way, switching "into" kernel-context is expensive if only because of the security procedures necessary. By turning garbage-collection into a system call, you've introduced a potential security issue into the kernel (and therefore: security-related slowdowns). If anything, you want to keep as much functionality outside of the kernel as possible. > You can't mark pointers as unused without locking/syncing because kernel can reallocate pointers in the middle of scanning, no? That's the only reason, isn't it? But in kernel you'd know about it and you could mark unused pointers in single, lock/synchronisation free pass, no? In other words you don't need to stop the world if you are in kernel space because you know about all reallocations that are happening? I would recommend that you write a malloc/free implementation by hand. All garbage collection is, is when free becomes a no-op, and all the work is done in the malloc() call. It turns out that "malloc()" has all the information for which nodes were allocated, as well as which ones are alive and/or dead. The kernel never has this information, because the malloc() call threw it away in the first place. If the programmer _had_ the information, they would have called free(). But the programmer decided that calling free() was either too hard, or error-prone for their use case, and decided to go with the easier malloc-only interface. That means that malloc() now has to work a lot harder to "rediscover" the locations of all pointers that must be freed. It doesn't matter if these routines are in the kernel, in user-space, or taking place on the moon over a TCP/IP port by carrier-pigeons. The fundamental tradeoff you have is that your code must rediscover live vs dead pointers on its own, independently from the programmer.

dragontamer 5y ago

> Couldn't this be solved with strategy hint flags if necessary? How is that easier than just the programmer choosing a garbage-collecting library and/or language that works for their use cases? Ex: Javascript / V8 gets this GC from this blogpost. Java gets their 3 or 4 command-line configurable GCs. Go gets their own. Lispers use their Lisp-gc implementation. Etc. etc. Because each programming community has a particular workflow / paradigm that works for them, each specific garbage collector is explicitly designed for each language's quirks. For example: Lisp "cons" is practically a constant-sized garbage collector, possibly implemented using bitsets because all car/cdrs are of a consistent size. Java is throughput focused by default, because of a large number of server-based customers. And of course: this Javascript / V8 focuses on latency optimization for the best UI responsiveness. > I don't understand why you'd have to do task switching in the first place. Wrong word. I meant system call. Either way, switching "into" kernel-context is expensive if only because of the security procedures necessary. By turning garbage-collection into a system call, you've introduced a potential security issue into the kernel (and therefore: security-related slowdowns). If anything, you want to keep as much functionality outside of the kernel as possible. > You can't mark pointers as unused without locking/syncing because kernel can reallocate pointers in the middle of scanning, no? That's the only reason, isn't it? But in kernel you'd know about it and you could mark unused pointers in single, lock/synchronisation free pass, no? In other words you don't need to stop the world if you are in kernel space because you know about all reallocations that are happening? I would recommend that you write a malloc/free implementation by hand. All garbage collection is, is when free becomes a no-op, and all the work is done in the malloc() call. It turns out that "malloc()" has all the information for which nodes were allocated, as well as which ones are alive and/or dead. The kernel never has this information, because the malloc() call threw it away in the first place. If the programmer _had_ the information, they would have called free(). But the programmer decided that calling free() was either too hard, or error-prone for their use case, and decided to go with the easier malloc-only interface. That means that malloc() now has to work a lot harder to "rediscover" the locations of all pointers that must be freed. It doesn't matter if these routines are in the kernel, in user-space, or taking place on the moon over a TCP/IP port by carrier-pigeons. The fundamental tradeoff you have is that your code must rediscover live vs dead pointers on its own, independently from the programmer.