clojure-dev

john 2026-05-04T23:07:28.840839Z

So, while working on https://github.com/SeniorCareMarket/eve (still not "officially" announced yet), I put a lot of thought into how to optimize atomic swaps. I figured out how to slightly optimize them. And I think I'll be able to further optimize them in the future. But I wanted to put it on y'alls radar, in case Clojure ever wanted to make the optimization. When two writers are swapping and one wins the epoch, if the losing writer kept track of all their read-paths across the hamt that they read within their swapping transaction, and then they check to see if the winning writer wrote over any of the loser's write OR read paths, then the loser knows they can safely graft back onto their new tree the original writes... So they don't have redo all their writes. I'm only implementing optimistic grafting naively right now - any touching branch invalidates the rest of the branches. But, I think, theoretically, if you have the read and write trees of all writers involved in a transaction, you can reconstruct an optimal re-graft on any given failure without having to recompute all of the execution. Maybe you can't do read tracking in clojure because the heap is invisible to the java user? Maybe you could use weak references or something, idk... No, you're walking the hamt so you should be able to do read tracking... Anyway, it's theoretical territory but I think regrafting could be useful for super large writes where you don't want to waste as much in contended transactions.

john 2026-05-04T23:19:07.751939Z

For me, it really makes more sense where the transactions are slower across disk. Maybe not as big of a deal in mem