Memory Allocation Strategies

mutablecode - watchpoints

Watchpoint-based bounds checking does offer free performance, but comes with list of exceptions and conditions:

Watchpoints are dependent on both the processor and operating system: the hardware must have the feature, and the software must expose it

When they are supported, setup may be slow (eg many system calls) or impose other requirements (eg forking on Linux)

Each side of a boundary check requires one watchpoint, of which there are relatively few (4 on x86, 16 on Arm)

Each end must also be padded by at least a word; memory before and after an array are used validly elsewhere

Only the boundary is checked: jumping past watchpoints is undetectable

When errors are detected, signal-driven logic makes graceful recovery difficult

Using a debugger is also difficult, as they too use the watchpoints

They add complexity

This list is not exhaustive; it shows watchpoints are nuanced and require careful thought and planning for correct usage.

Looking forward, compilers could treat watchpoints like another register resource, automatically using them for bounds checking and other creative uses. Beyond twisting them into bounds checkers, watchpoints are more commonly found in debuggers like lldb and gdb, although a program could provide its own debugging capabilities; the example code is essentially the skeleton of a debugger.