7:25. I've got some news on this: en.m.wikipedia.org/wiki/Intel_5-level_paging. Such stuff emerging here and there means that the "pointer tagging" thingie is broken by design.
12:35 - I don't think this is an intuitive way to explain the probability of bugs (I'm not sure if it's correct either). Can someone clarify this bit ? Why would the possibility of catching a bug be 15/16 (for 4 bit tag case) or 255/256 (for 8 bit tag case) ? For example: Let the pointer have green tag. Let the corresponding memory have green tag. Now, if there can be a lot of memory chunks, you could easily and incorrectly access the same (green here) coloured chunk somewhere else in the memory. I don't see how you can quantify the possibility of catching a bug if the memory has a lot of coloured chunks.
"you could easily and incorrectly access the same (green here) colored chunk" The probability of this chunk being colored with green is 1/(2^Tag_bits) and the probability of this chunk being colored with another color is (2^tag_bits - 1)/(2^tag_bits) (As far as i get how it works)
I just saw this talk... probably you found the answer but in case someone else is asking the same thing: It's because on a 4 bit tag you can store 2^4 = 16 values (0000, 0001, 0010, 0011, 0100, 0101, ... , 1111) the chances that the tag of a dangling pointer matches the tag of the memory it's pointing is 1/16. In other words in 15/16 cases you will catch the bug. the same for 8 bits => 2^8 = 256 values so in 255/256 of cases you will catch the bug. if it's still not clear you can simplify the problem for 1 bit, then go to 2 bits, etc. in general for a tag of n bits it's (2^n -1) / (2^n) chance of catching the buggy memory access.
@@andreicheremukhin3082 I mostly do maintenance contracts for small customers now, so mainly yes, ATM. But these bugs have always been easily avoidable, even in C. Most of the bugs in older code are due to uninitialized variables.
@@tikabass Yes, it works if you have expirienced teammates. But in big tech companies you can have people with different background and C++ expirience (e.g. Java programmers). And ASAN and MT are great tools, indeed.
Great presentation!
7:25. I've got some news on this: en.m.wikipedia.org/wiki/Intel_5-level_paging. Such stuff emerging here and there means that the "pointer tagging" thingie is broken by design.
One group of Google programmers writes crappy buggy software, and another one develops methods to catch those bugs...
I wonder if everyone's favourite vendors Intel and AMD are going to provide hardware memory tagging.
Given the massive overhead and minimal benefit, I doubt it
12:35 - I don't think this is an intuitive way to explain the probability of bugs (I'm not sure if it's correct either).
Can someone clarify this bit ? Why would the possibility of catching a bug be 15/16 (for 4 bit tag case) or 255/256 (for 8 bit tag case) ?
For example:
Let the pointer have green tag. Let the corresponding memory have green tag. Now,
if there can be a lot of memory chunks, you could easily and incorrectly access the same (green here) coloured chunk
somewhere else in the memory.
I don't see how you can quantify the possibility of catching a bug if the memory has a lot of coloured chunks.
"you could easily and incorrectly access the same (green here) colored chunk"
The probability of this chunk being colored with green is 1/(2^Tag_bits) and the probability of this chunk being colored with another color is (2^tag_bits - 1)/(2^tag_bits)
(As far as i get how it works)
I just saw this talk... probably you found the answer but in case someone else is asking the same thing:
It's because on a 4 bit tag you can store 2^4 = 16 values (0000, 0001, 0010, 0011, 0100, 0101, ... , 1111) the chances that the tag of a dangling pointer matches the tag of the memory it's pointing is 1/16. In other words in 15/16 cases you will catch the bug. the same for 8 bits => 2^8 = 256 values so in 255/256 of cases you will catch the bug.
if it's still not clear you can simplify the problem for 1 bit, then go to 2 bits, etc. in general for a tag of n bits it's (2^n -1) / (2^n) chance of catching the buggy memory access.
I haven't had any of these bugs in the last 15 years, because they are very easy to avoid. Do they teach anything in college?
Do you write software alone on your own?
@@andreicheremukhin3082 I mostly do maintenance contracts for small customers now, so mainly yes, ATM. But these bugs have always been easily avoidable, even in C. Most of the bugs in older code are due to uninitialized variables.
@@tikabass Yes, it works if you have expirienced teammates. But in big tech companies you can have people with different background and C++ expirience (e.g. Java programmers). And ASAN and MT are great tools, indeed.
@@andreicheremukhin3082 Which is exactly why I ask if they teach anything useful in college.