News for hackers. Stuff that matters.
Re:Reference count, don't garbage collect by hinkley on Friday July 29, 2022 @06:11PM (#32282354)
I don't know what the current state of the art is, but at one point the answer to GC in a realtime environment was to amortize free() across malloc(). Each allocation would clear up to 10 elements from queue of free-able memory locations. That gives a reasonably tight upper bound on worst case alloc time, and most workflows converge on a garbage-free heap. Big malloc after small free might still blow your deadlines, but big allocations after bootstrapping are generally frowned upon in realtime applications, so that's as much a social problem as a technical one.
Re:Reference count, don't garbage collect by pclmulqdq on Friday July 29, 2022 @08:01PM (#32283039)
This is normal today inside malloc implementations.
Re:Reference count, don't garbage collect by hinkley on Saturday July 30, 2022 @11:32AM (#32287575)
I think that’s been normal in malloc for some time. I maintain that we should all thank Java, and the hype train around it, for forcing operating systems to implement more robust threading support. Everyone wanted to be able to say they did Java well, and nearly every OS had capital ‘I’ Issues, including Solaris. Boy I bet those closed room arguments were epic.

Where GCed languages pulled ahead for a while, particularly Java, was that they had mature concurrent memory allocation before most OSes did, so many people found on early two and four core hardware that malloc started to show up as a bottleneck.