@daniil14056
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 раз Счетчик для каждого блока увеличить, и еще наверное сравнить этот счетчик, с каким-то минимум для оптимизации. (А после оптимизации все эти счетчики и сбор статистики убираются надеюсь?)
А еще не могу понять, как на эмуляторах при исполнение клиентского кода, как кода выше, эмулятор обрабатывает адрес, типа максимально эффективно, вообще не обрабатывать, но тогда ошибки в памяти вызовут ошибку на хосте, а хакер дак и вообще может через эмулятор взломать внешнею систему.
А делать доп проверки то же дорого будет, так как это каждая вторая операция.
Решения вопроса 0
Ответы на вопрос 2
@mayton2019
Как Jit Компиляторы обнаружат недостижимой код и лишние проверки?
Если мне не изменяет память, JIT компиллятор компилирует java-метод целиком. Переводя byte-code в машинный код для x86 например.
А то что спрашивает автор — это задача основного компиллятора который язык Java переводит в байткод.
о тогда ошибки в памяти вызовут ошибку на хосте, а хакер дак и вообще может через эмулятор взломать внешнею систему.
ли Космические Лучи, в Ram попали, что тогда будет?
Программисты 20-го века работали в условиях глючной памяти (когда были ЭВМ на лампах и на тразнисторах)
и обрабатывали специальное прерывание типа «глюк в ячейке памяти».
С точки зрения современной парадигмы разработки — это невозможно. Никакой прикладной
программист не ставит себе задачу отслеживания целостности памяти. Это как-бы не его
уровень. Мы предполагаем что память надежна и всегда корректна. А иначе ОС выпадает
в синий экран и никаких принятий решения мы все равно не сделаем а облачные балансировщики
примут свои решения когда хост выпадет из сети.
В современной ОС также по дефолту считается что никакой хакер никогда не меняет
память вашего процесса. Это — основа безопасности ОС и если хакер все таки что-то может
менять — то это плохая ОС и плохая безопасность и надо что-то решать на уровне системной
архитектуры и тем более прикладной программист здесь ничего не сможет сделать.
Рассматривать такие случаи в топике Java — бесполезно и контр-продуктивно. Давайте
их рассматривать в топиках инфо-беза и операционок.
@Wan-Derer
Вот на этапе предварительной компиляции и происходит проверка «статики»: скобку не поставил, задал индекс явно не в границах массива, оставил какой-то код после
return, забыл вернуть значение из метода, напутал с типами и т.п.Но это не спасает от ошибок в рантайме: если индекс для массива вычисляется, а потом ты пытаешься достать элемент по этому индексу, то проверка на границы — на твоей совести, а железка, если что, просто упадёт с исключением 🙂