Because the industry has plenty of experience with referece counting as the very first GC algorithm, already in the early 1960's, in early Lisp implementations, BASIC, Cedar, and several other languages.

The predictable runtime performance is also a myth, because they never take into account the use of NUMA memory, lock contention, possible stack overflow and stop the world in the case of cascaded deletions in naive implementations.

▲

raverbashing 2 hours ago | parent [-]

Lock contention yes, it's fundamentally a RC issue, but makes me think per-thread objects make more sense

I'm not sure most GC implementations worry about the rest neither (as by the several complaints we see going around)

▲

pjmlp an hour ago | parent [-]

The ones across several JVM implementations (there is a world beyond OpenJDK), and the CLR certainly do.

▲

raverbashing an hour ago | parent [-]

Yes, and the fact you have to have a "special GC" for your case makes me wonder that those constraints are not so obvious.

(makes me wonder who's buying those - things like Azul, etc)

	▲	pjmlp 13 minutes ago \| parent [-]
		Places that were doing C++, but found out that the right GC, and JIT compiler, can achieve good enough performance for their business case. There is nothing "special GC" about it, the failure is to assume there is only one way to implement GC algorithms, as if there is only one way to implement hash tables, tree re-balancing algorithms, .... and then place all languages into the same bucket. Then we have the modern times with AI driven code generation, where no one cares how their agents are actually doing the work, with what kinds of resource management approaches.