3 ms·
First, please clarify whether you are asking about performance impacts vs. no bounds checking or vs. bounds checking in software. The "vs. no bounds checking"
by moring 3y ago
First, please clarify whether you are asking about performance impacts vs. no bounds checking or vs. bounds checking in software.
The "vs. no bounds checking" deals with the fact that the bounds must be stored somewhere, so you get an additional memory access, and that's slow (best case, puts some load on the caches).
The "vs. software" is more like RISC vs. CISC in general.
- g-b-r 3y ago> First, please clarify whether you are asking about performance impacts vs. no bounds checking or vs. bounds checking in software I was wondering if it would be feasible to have hardware checks with practically no speed difference to performing no check at all. Yes I imagined it could be seen as RISC vs CISC, but it's such a fundamental and frequent operation that it seems likely it would help overall..! Of course you'd need to use registers; which yes means higher cost (unless you already have some for sure never in use at bound-checking times), but there seems to be a good chance it would be worthwhile..? I imagine that the impact of simply reading the additional instructions would be negligible, by the way
- kaba0 3y agoCHERI might allow for that?
- moring 3y agoThe cost is in loading the bounds (e.g. array size) from memory. If you access 100 different arrays, you get 100 load operations for the sizes. A register would only help if you access the same array in a loop, but the majority of loops doesn't need repeated bounds checking anyway: list-map operations, list-reduce operations, System.arraycopy(), whatever -- these only have to check the bounds once before starting the loop. The JVM specifies that every array access gets checked, but since arrays can't change their size, the JIT compiler can move that check outside the loop.