[Someone]

“Huge/Large/Super pages” (https://wiki.debian.org/Hugepages) exist because the typical 4kB pages have too much overhead in programs that allocate lots of memory.

So, sizing pages down to malloc-sized blocks will impact performance, even ignoring the fact that, to have true bounds checking, pointers will have to carry size information, making them larger (64-bit pointers have quite a few unused bits on typical systems, so it may be possible to hide that somewhat.

Also, if you truly want to do bounds-checking, you will have to create a ‘page’ for every element of every array (either up front or on demand), and, if such elements have structure, for each part of the structure.

[CoolGuySteve]

Huge pages mainly exist to alleviate TLB pressure and page fault latency. But that performance penalty is tiny compared to the alternative of in-program bounds checking that we currently use.

Similarly, pointers don't necessarily need to be changed and your array problem isn't valid. Cachelines could be marked with canaries that fault on read/write, similar to how the NX bit currently works.

The NX bit is actually a good example of a hardware security-performance trade off that nearly everyone agrees on. Now 20 years later, we can afford to mark several more bits at some cache offset for a hardware bounds field.