Как Jit Компиляторы обнаружат недостижимой код и лишние проверки?

Question

[Даниил]

for(int i=0;i<len;i++)
     if(i>=0)
         arr[i]=i;
;;;;;;;;;;;;;;;;;;;;;;;
//.....
for(int i=1;i<len;i++)
     if(i>0)
         i=arr[i];

В java раньше вроде в какой-о версии, каждый доступ к массиву проверялся на границы, в добавок.
Как во втором цикле будет удалена проверка if( i> 0), откуда компилятору известно что arr[i] будет больше 0.
А вдруг его через другой поток, через другой процесс хакер в редакторе исправил, или Космические Лучи, в Ram попали, что тогда будет?
Не понимаю, как вообще можно удалить проверку. И как ее вернуть.
А еще не понимаю, как собирают статистику, типа помимо того что бы проверить некое условие N раз, дак еще и N раз Счетчик для каждого блока увеличить, и еще наверное сравнить этот счетчик, с каким-то минимум для оптимизации. (А после оптимизации все эти счетчики и сбор статистики убираются надеюсь?)

А еще не могу понять, как на эмуляторах при исполнение клиентского кода, как кода выше, эмулятор обрабатывает адрес, типа максимально эффективно, вообще не обрабатывать, но тогда ошибки в памяти вызовут ошибку на хосте, а хакер дак и вообще может через эмулятор взломать внешнею систему.
А делать доп проверки то же дорого будет, так как это каждая вторая операция.

Answer 1

[mayton2019]

Как Jit Компиляторы обнаружат недостижимой код и лишние проверки?

Если мне не изменяет память, JIT компиллятор компилирует java-метод целиком. Переводя byte-code в машинный код для x86 например.

А то что спрашивает автор - это задача основного компиллятора который язык Java переводит в байткод.

о тогда ошибки в памяти вызовут ошибку на хосте, а хакер дак и вообще может через эмулятор взломать внешнею систему.

ли Космические Лучи, в Ram попали, что тогда будет?

Программисты 20-го века работали в условиях глючной памяти (когда были ЭВМ на лампах и на тразнисторах)
и обрабатывали специальное прерывание типа "глюк в ячейке памяти".

С точки зрения современной парадигмы разработки - это невозможно. Никакой прикладной
программист не ставит себе задачу отслеживания целостности памяти. Это как-бы не его
уровень. Мы предполагаем что память надежна и всегда корректна. А иначе ОС выпадает
в синий экран и никаких принятий решения мы все равно не сделаем а облачные балансировщики
примут свои решения когда хост выпадет из сети.

В современной ОС также по дефолту считается что никакой хакер никогда не меняет
память вашего процесса. Это - основа безопасности ОС и если хакер все таки что-то может
менять - то это плохая ОС и плохая безопасность и надо что-то решать на уровне системной
архитектуры и тем более прикладной программист здесь ничего не сможет сделать.

Рассматривать такие случаи в топике Java - бесполезно и контр-продуктивно. Давайте
их рассматривать в топиках инфо-беза и операционок.

Answer 2

[Wan-Derer]

Если я правильно понял вопрос, то наличие JIT-компилятора не отменяет обычный. Т.е. код сначала "предкомпилируется" к некий кроссплатформенный код, который уже потом исполняется на виртуальной машине (JVM).
Вот на этапе предварительной компиляции и происходит проверка "статики": скобку не поставил, задал индекс явно не в границах массива, оставил какой-то код после return, забыл вернуть значение из метода, напутал с типами и т.п.
Но это не спасает от ошибок в рантайме: если индекс для массива вычисляется, а потом ты пытаешься достать элемент по этому индексу, то проверка на границы - на твоей совести, а железка, если что, просто упадёт с исключением :)