Interesting progress on safe type casting in Rust. This should bring nice zero copy parsing of binary data in some cases.

Data layout is essential for performance reasons. It is too often overlooked. If you want real speed you need to help the memory subsystem.

Good reminder that packing your data is generally the right move when squeezing for performances.

Interesting point. As the memory safety of our APIs will increase, can we reduce the amount of sandboxing we need? This will never remove completely the need if only for logic bugs, but surely we could become more strategic about it.

Funny musing about the OOM killer. With nice pointers if you want to dive further into the topic.

There are many ways to create a memory leak in Javascript. Here is a good list of the things to pay attention to.

Interesting, it confirms garbage collectors can be the source of unrecoverable performance degradation in request based systems.

Interesting take, those bugs are more convenient to exploit. Logic bugs are too specific to easily exploit at scale.

Definitely this. C++ isn't going away anytime soon. Rewrites won't be worth it in important cases, so improving the safety of the language matters.

If you needed to be reminded that allocating small blocks of memory is a bad idea... here is a paper explaining it.

Interesting dive into how join() and generator behave in CPython.

Interesting quick comparison, this shows the design tradeoffs quite well.

Interesting case... even though honestly we shouldn't need to dig out this kind of details.

Improved static analysis for C straight from GCC. This is definitely welcome.

This is indeed a more interesting way to perceive garbage collection. This also lead to proper questions to explore on the topic.

Nice balanced view on some of Rust characteristics. This is much less naive than some of the "Rust is great" posts out there.

Making your own allocator? This is definitely something to consider and measure.

Excellent piece from Herb Sutter once again. This is a very well balanced view about language safety and how far C++ could go in this direction. This is a nice call to action, would like to see quite some of that happen.

Indeed, not all security issues are due to memory related problems. It's 20% of the security issues. This is of course massive, but there's still 80% of the security issues coming from wrong authentication, appliances and so on.

Very interesting talk. It gives a good idea of some properties of the JVM memory model. It also shows how the CPU architecture properties can leak all the way through changing some of the behavior of JVM code. Too bad this particular thing seems badly documented on the JDK side.