4 ms·

> Traditional AOT languages don't make promises about what happens if you try to dereference null. And they don't depend on a page fault happening. The languag

> Traditional AOT languages don't make promises about what happens if you try to dereference null. And they don't depend on a page fault happening. The language doesn't make any promise yet on every major platform for the last 40 years a null deref resulted in a segfault because the lower address space is marked invalid. This is absolutely, 100% baked into the practical expectations of every traditional AOT language at this point. > For higher level runtimes, can you name some common ones that use page faults that way? Android's ART does. I'd be shocked if OpenJDK doesn't for the same reason. Same with .NET or any other mature JIT runtime. It's obviously ridiculously expensive to insert null checks before every object access, and since the CPU & some page protections can do it for free why would you pay that?

Dylan16807 3y ago
> The language doesn't make any promise yet on every major platform for the last 40 years a null deref resulted in a segfault because the lower address space is marked invalid. If you're using an offset that's not super reliable, and some major platforms of the past 40 years do give you memory at or near zero, and of course with a language like C the compiler is allowed to assume it won't be null and that can cause all sorts of weird program corruption even when a page fault would be safe-ish.
neonsunset 3y ago
> It's obviously ridiculously expensive to insert null checks before every object access This is actually the other way around. Both .NET and JVM do it the same way - they inject the smallest instruction that dereferences a pointer (e.g. cmp byte ptr [rax], al or ldr xzr, [x2]) and when it throws a hardware exception, it is then caught by the registered runtime handler, which then subsequently resumes the execution of managed code from the hardware exception location and raises corresponding Null Reference/Pointer exception there. The only expensive part is when the exception does get raised, which costs roughly 4us in .NET and 11us in OpenJDK hotspot (Java has cheaper exceptions when you throw them out of Java, costing about 700ns at throughput, but much more expensive NPEs). As a result, null-checks are almost always cheap, or free by being implicit (reading array length can be a null-check itself since it will be dereferencing nullptr + 0x08 or so depending on the implementation detail), and the compilers are pretty good at eliding them as well where possible.
- kllrnohj 3y ago
  Yes, but this doesn't work in webassembly because 0x0 is a valid address. That's my point. To do .NET & JVM in webassembly requires doing an actual null comparison and branch as you no longer get to just deref and catch the resulting segfault as there won't be a segfault. So you have to do an actual branch everywhere, which makes null checks way way more expensive.
flohofwoe 3y ago
> on every major platform for the last 40 years a null deref resulted in a segfault Not on the Amiga ;)

Dylan16807 3y ago

> The language doesn't make any promise yet on every major platform for the last 40 years a null deref resulted in a segfault because the lower address space is marked invalid. If you're using an offset that's not super reliable, and some major platforms of the past 40 years do give you memory at or near zero, and of course with a language like C the compiler is allowed to assume it won't be null and that can cause all sorts of weird program corruption even when a page fault would be safe-ish.

neonsunset 3y ago

> It's obviously ridiculously expensive to insert null checks before every object access This is actually the other way around. Both .NET and JVM do it the same way - they inject the smallest instruction that dereferences a pointer (e.g. cmp byte ptr [rax], al or ldr xzr, [x2]) and when it throws a hardware exception, it is then caught by the registered runtime handler, which then subsequently resumes the execution of managed code from the hardware exception location and raises corresponding Null Reference/Pointer exception there. The only expensive part is when the exception does get raised, which costs roughly 4us in .NET and 11us in OpenJDK hotspot (Java has cheaper exceptions when you throw them out of Java, costing about 700ns at throughput, but much more expensive NPEs). As a result, null-checks are almost always cheap, or free by being implicit (reading array length can be a null-check itself since it will be dereferencing nullptr + 0x08 or so depending on the implementation detail), and the compilers are pretty good at eliding them as well where possible.

kllrnohj 3y ago
Yes, but this doesn't work in webassembly because 0x0 is a valid address. That's my point. To do .NET & JVM in webassembly requires doing an actual null comparison and branch as you no longer get to just deref and catch the resulting segfault as there won't be a segfault. So you have to do an actual branch everywhere, which makes null checks way way more expensive.

flohofwoe 3y ago

> on every major platform for the last 40 years a null deref resulted in a segfault Not on the Amiga ;)