A lot of frameworks that use variants of "mark and sweep" garbage collection instead of automatic reference counting are built with the assumption that RAM is cheap and CPU cycles aren't, so they are highly optimized CPU-wise, but otherwise are RAM inefficient.
I wonder if frameworks like dotnet or JVM will introduce reference counting as a way to lower the RAM footprint?
Reference counting in multithreaded systems is much more expensive than it sounds because of the synchronization overhead. I don't see it coming back. I don't think it saves massive amounts of memory, either, especially given my observation with vmmap upthread that in many cases the code itself is a dominant part of the (virtual) memory usage.
If you use an ownership/lifetime system under the hood you only pay that synchronization overhead when ownership truly changes, i.e. when a reference is added or removed that might actually impact the object's lifecycle. That's a rare case with most uses of reference counting; most of the time you're creating a "sub"-reference and its lifetime is strictly bounded by some existing owning reference.
There are 2 unavoidable atomic updates for RC, the allocation and the free event. That alone will significantly increase the amount of traffic per thread back to main memory.
A lifetime system could possibly eliminate those, but it'd be hard to add to the JVM at this point. The JVM sort of has it in terms of escape analysis, but that's notoriously easy to defeat with pretty typical java code.
> Why would an allocation require an atomic write for a reference count?
It won't always require it, but it usually will because you have to ensure the memory containing the reference count is correctly set before handing off a pointer to the item. This has to be done almost first thing in the construction of the item.
It's not impossible that a smart compiler could see and remove that initialization and destruction if it can determine that the item never escapes the current scope. But if it does escape it by, for example, being added to a list or returned from a function, then those two atomic writes are required.
Incrementing or decrementing a shared counter is done with an atomic instruction, not with a locked critical section.
This has negligible overhead in most cases. For instance, if the shared counter is already in some cache memory the overhead is smaller than a normal non-atomic access to the main memory. The intrinsic overhead of an atomic instruction is typically about the same as that of a simple memory access to data that is stored in the L3 cache memory, e.g. of the order of 10 nanoseconds at most.
Moreover, many memory allocators use separate per-core memory heaps, so they avoid any accesses to shared memory that need atomic instructions or locking, except in the rare occasions when they interact with the operating system.
Atomic operations, especially RMW operations are very expensive, though. Not as expensive as a syscall, of course, but still a lot more expensive than non-atomic ones. Exactly because they break things like caches
Not only that, they write back to main memory. There's limited bandwidth between the CPU and main memory and with multithreading you are looking at pretty significantly increasing the amount of data transferred between the CPU and memory.
This is such a problem that the JVM gives threads their own allocation pools to write to before flushing back to the main heap. All to reduce the number of atomic writes to the pointer tracking memory in the heap.
Unlikely. Maybe I'm overly optimistic, but I think it's fairly likely that the RAM situation will have sorted itself out in a few years. Adding reference counting to the JVM and .NET would also take considerable time.
It makes more sense for application developers to think about the unnecessary complexity that they add to software.
That's not strictly true. Mark and sweep is tunable in ways ARC is not. You can increase frequency, reducing memory at the cost of increased compute, for example.
M&S also doesn't necessitate having a moving and compacting GC. That's the thing that actually makes the JVM's heap greedy.
Go also does M&S and yet uses less memory. Why? Because go isn't compacting, it's instead calling malloc and free based on the results of each GC. This means that go has slower allocation and a bigger risk of memory fragmentation, but also it keeps the go memory usage reduced compared to the JVM.
Compacting reduces memory usage - that's why it's called compacting.
The JVM uses a lot of memory a) because it's tuned for servers and not for low memory usage and b) because Java is a poorly designed language without value types.
Basically, the short answer is that most memory managers allocate more memory than a process needs, and then reuse it.
IE, in a JVM (Java) or dotnet (C#) process, the garbage collector allocates some memory from the operating system and keeps reusing it as it finds free memory and the program needs it.
These systems are built with the assumption that RAM is cheap and CPU cycles aren't, so they are highly optimized CPU-wise, but otherwise are RAM inefficient.
I know of one person who was born physically a woman, but has XY chromosomes. It is only due to modern medicine that we know that there is anything "unusual" with her gender. Otherwise, she is physically a woman with no observable clues to her condition.
(IE, in the past, she would have been infertile, and probably died young due to her situation.)
I'm not comfortable with saying that people like her need to compete with men.
Complete androgen insensitivity syndrome, I imagine? That's probably the one category of XY people who have undergone no hormonal masculinization throughout their lives, and the one case where I'd agree with them competing with women. Wikipedia says it's estimated to be "1 in 20,400 to 1 in 99,000".
Assuming you live in a "large" western home, it's impractical. Remember, Edison's first power grid operated at 110/220v DC to the home. If there was lower voltage (IE, 12 volts) going from the street to your walls, the line loss would be significant. It only works in RVs and shacks because the wires are short.
Thus, even if you had DC in the walls, it would be 100+ volts, and you'd still have conversion down to the lower voltages that electronics use. If you look at the comments in this thread from people who work in telco, they talk about how voltage enters equipment at -48V and is then further lowered.
Most of those faux pas come across as neurotic, like complaining about people who park too close to the lines, or complaining about someone farting in church.
Seems like someone could make a sketch comedy skit where someone does these faux pas, and most people don't notice except the one person who has a perpetual wedgie.
> Most people don’t like computers. Nobody in tech wants to say that out loud. People tolerate computers. They use them because they have to. Given the choice, most would rather not think about them at all.
Which makes me think there's a lot more room for "virtual people." Imagine a very smart AI bot that could hold multiple conversations at once and remember a lot of things.
> So when someone suggests that AI means everyone will build their own custom tools, ask who "everyone" is. The three-person accounting firm drowning in client paperwork? They want the paperwork gone, not a new system to maintain. The regional logistics company with 40 trucks? They want the routes optimized, not Joe spouting off about this new system he’s been messing around with. The law firm billing 70-hour weeks? They want leverage on their time, not a software project to design.
What if there was a bot that was just smart enough to figure those things out, without needing traditional "software"?
To me, that's more what AI is, instead of adding chatbots to everything, and vibecoding everything.
that's a good way to frame it, but it boils down to: what is it that these entities or individuals do that is valuable and how do you replicate parts or the whole of it.
which is essentially the direction that were heading in: we're sequentially and iteratively building improvements.
what the logistics company did pre computers and even pre trucks was not all that different in many aspects.
I wonder if frameworks like dotnet or JVM will introduce reference counting as a way to lower the RAM footprint?
reply