Comments URL: https://news.ycombinator.com/item?id=49184757

Points: 369

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=48939831

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48864111

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48863473

Points: 2

# Comments: 0

https://developer.meta.com/ai/resources/blog/build-with-muse...

https://www.bloomberg.com/news/articles/2026-07-09/meta-star..., https://archive.is/3ccKa

Comments URL: https://news.ycombinator.com/item?id=48846184

Points: 413

# Comments: 214

For me, the reading that made asymmetric fences "click" is this: https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-r...

It might be easier to read that first, as it also goes into practical applications, and then this one.

I think you mean readline?

Comments URL: https://news.ycombinator.com/item?id=48484079

Points: 2

# Comments: 0

Information quantities are more meaningfully expressed in number of bits.

Comments URL: https://news.ycombinator.com/item?id=48070161

Points: 61

# Comments: 42

Comments URL: https://news.ycombinator.com/item?id=48047349

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47940183

Points: 9

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47874601

Points: 5

# Comments: 0

A 0.5% improvement may not be a lot to you, but at hyperscaler scale it's well worth staffing a team to work on it, with the added benefit of having people on hand that can investigate subtle bugs and pathological perf behaviors.

If the allocator returns a page to the kernel and then immediately asks back for one, it's not doing its job well: the main purpose of the allocator is to cache allocations from the kernel. Those patches are pre-decay, pre-background purging thread; these changes significantly improve how jemalloc holds on to memory that might be needed soon. Instead, the zeroing out patches optimize for the pathological behavior.

Also, the kernel has since exposed better ways to optimize memory reclamation, like MADV_FREE, which is a "lazy reclaim": the page stays mapped to the process until the kernel actually need it, so if we use it again before that happens, the whole unmapping/mapping is avoided, which saves not only the zeroing cost, but also the TLB shootdown and other costs. And without changing any security boundary. jemalloc can take advantage of this by enabling "muzzy decay".

However, the drawback is that system-level memory accounting becomes even more fuzzy.

(hi Alex!)

In the original paper they do not give it any name: https://people.csail.mit.edu/rivest/Rsapaper.pdf

RE2 resets the cache when it reaches a (configurable) size limit. Which I found out the hard way when I had to debug almost-periodic latency spikes in a service I managed, where a very inefficient regex caused linear growth in the Lazy DFA, until it hit the limit, then all threads had to wait for its reset for a few hundred milliseconds, and then it all started again.

I'm not sure if dropping the whole cache is the only feasible mitigation, or some gradual pruning would also be possible.

Either way, if you cannot assume that your cache grows monotonically, synchronization becomes more complicated: the trick mentioned in the other comment about only locking the slow path may not be applicable anymore. RE2 uses RW-locking for this.

Comments URL: https://news.ycombinator.com/item?id=47276180

Points: 1

# Comments: 0