Programming Leftovers
-
Andy Wingo: partitioning pitfalls for generational collectors
You might have heard of long-pole problems: when you are packing a tent, its bag needs to be at least as big as the longest pole. (This is my preferred etymology; there are others.) In garbage collection, the long pole is the longest chain of object references; there is no way you can algorithmically speed up pointer-chasing of (say) a long linked-list.
As a GC author, some of your standard tools can mitigate the long-pole problem, and some don’t apply.
Parallelism doesn’t help: a baby takes 9 months, no matter how many people you assign to the problem. You need to visit each node in the chain, one after the other, and having multiple workers available to process those nodes does not get us there any faster. Parallelism does help in general, of course, but doesn’t help for long poles.
You can apply concurrency: instead of stopping the user’s program (the mutator) to enumerate live objects, you trace while the mutator is running. This can happen on mutator threads, interleaved with allocation, via what is known as incremental tracing. Or it can happen in dedicated tracing threads, which is what people usually mean when they refer to concurrent tracing. Though it does impose some coordination overhead on the mutator, the pause-time benefits are such that most production garbage collectors do trace concurrently with the mutator, if they have the development resources to manage the complexity.
Then there is partitioning: instead of tracing the whole graph all the time, try to just trace part of it and just reclaim memory for that part. In most programs the odds of a long pole are proportional to the graph size, and so tracing a graph subset should reduce total pause time.
The usual way to partition is generational, in which the main program allocates into a nursery, and objects that survive a few collections then get promoted into old space.
-
Godot Engine ☛ Dev snapshot: Godot 3.6 beta 5
This beta represents feature freeze for 3.6. We will now concentrate on bug fixing until we reach stable.
-
Rlang ☛ Four-dimensional torus knots
Here is a parameterization of a four-dimensional torus knot: [...]
-
Qt ☛ It's Survey Time: Qt Framework + Squish Evaluation
tldr; We have two open evaluation questionnaires for our users [...]
-
Perl / Raku
-
Rakulang ☛ Raku Weekly 2024.20 Doc Announcing
Thanks to the work of Richard Hainsworth and the Raku documentation and Raku infra team, the Raku Documentation website now has a date-stamped list of announcements. And every time there’s a new announcement, this will appear in a popup window (unless you disable that feature). Kudos!
-
-
Java
-
Eric Hameleers ☛ Slackware: Java updates for 2024Q2
Three weeks ago, the quarterly (security and stability) updates to various Java source code repositories were released. This means, new packages for OpenJDK versions 8, 11 and 17 are now in my Slackware repository.
-
-
GNU Projects
-
GNU ☛ libtool @ Savannah: libtool-2.5.0 released [alpha]
Libtoolers! The Libtool Team is pleased to announce the release of libtool 2.5.0, a alpha release. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. There have been 91 commits by 29 people in the 113 weeks since 2.4.7. See the NEWS below for a brief summary. Thanks to everyone who has contributed!
-