CumingSoon
Местный стендапер
- 1,634
- 12
- 270
Там ещё пустой массив есть, который ничего не делает. Тоже где-то в Minecraft.java
Какого?!?!
- Автор темы Icosider
- Дата начала
-
- Теги
- code mojang wtf?! wtf!?!
- 1,870
- 52
- 360
И подобных методов множество.
- 3,649
- 100
- 718
И что тебя удивляет? Ничего сверхестественного не вижу.
tox1cozZ
aka Agravaine
- 8,453
- 599
- 2,906
Это он аллокейтит 10мб оперативки, чтобы если ее нет, то сразу игра вылетела и Майн не запускался)
Там комментарий есть)
CumingSoon
Местный стендапер
- 1,634
- 12
- 270
Лол)0)
Оптимальное решение для компьютеров 21 века проверять 10мб в наличии
Оптимальное решение для компьютеров 21 века проверять 10мб в наличии
- 2,932
- 44
- 599
Постоянно? Или один раз проверил и всё? (Я просто этот кусок кода не вижу... И не понимаю о чём вы.)
- 1,108
- 47
- 425
Хоба нашел доки.
На сколько я понимат: Java машина стоят - время не обновлят. Если все потоки стоят => Java машина стоят. Главный поток стоят, но демон-поток работат => Java машина работат.
Это все имхо я ведь не шарю.
Код:
Returns the current value of the running Java Virtual Machine's
high-resolution time source, in nanoseconds.
<p>This method can only be used to measure elapsed time and is
not related to any other notion of system or wall-clock time.
The value returned represents nanoseconds since some fixed but
arbitrary <i>origin</i> time (perhaps in the future, so values
may be negative). The same origin is used by all invocations of
this method in an instance of a Java virtual machine; other
virtual machine instances are likely to use a different origin.Это все имхо я ведь не шарю.
- 1,870
- 52
- 360
Почему наносекунды? там же милли?
- 2
- 9
Проблема достаточно древняя и корни её уходят глубоко в JVM и OS, поэтому извините за неточности, возможные ошибки и "пробелы".
Начать, наверное, стоит с того, как работает Thread.sleep. Основная задача такого метода - поставить поток на "паузу", на некоторое время. Обычно, в момент вызова такого метода, JVM обращается к операционной системе, а именно, к такой штуке как thread scheduler. Как может быть понятно из названия, он заведует подобными манипуляциями с потоками. Но, для JVM так же важно вовремя пробудить поток, так как изначально в методе sleep был указан интервал. Что бы иметь такую возможность, JVM не всегда использует методы самой операционной системы. Так, JVM от Sun(Компания, которая разрабатывала Java до Oracle, думаю знаете), отправляла поток в специальный пул, который с некоторой периодичностью опрашивался на предмет пробуждения. Такой себе ивент. И, обычно, у каждой ОС был свой такой период вызова ивента. Для Linux - 1ms, для Windows - 10-15ms. Ну, и всё хорошо себе работало. До момента, когда в 2001 году(Это была Java 3) был обнаружен баг: Если выставлять в Thread.sleep слишком маленький интервал, системные часы Windows станут идти быстрее! Круто, да?)
Ну, баг пофиксили, методом перехвата установки интервала с ОС, на JVM, теперь она контролировала это дело и всегда устанавливала 1ms. И что бы вы думали? В 2006 году оказывается, что при фиксе первого бага, был допущен ещё один баг, в связи с которым, интервал практически никогда так и не устанавливался на 1мс. Случилось так потому, что код фикса был написан не в том dll и не учитывал некоторый интервал при работе с терминалом. Но, за всё это время(около 5 лет), разработчики не получили ни одного репорта, поэтому решили, что лучше не трогать, раз уж так работает. Но что делать, если кто-то разрабатывал программу(Судя по тому треду, Майнкрафт был одним из таких программ), которой очень важно было, что бы её потоки пробуждались строго в указанное время? К счастью, этот интервал можно было установить самому, с помощью некоторого хака. Более того, такой интервал можно было установить не per-thread, а per-program! В общем, как вы уже догадались, этим хаком и был код выше, суть которого была в том, что бы с помощью создания демона, который вечно спит, минимизировать этот самый интервал пробуждения. Таким образом, была достигнута максимальная точность, где требовались какие-либо операции со временем.
Начать, наверное, стоит с того, как работает Thread.sleep. Основная задача такого метода - поставить поток на "паузу", на некоторое время. Обычно, в момент вызова такого метода, JVM обращается к операционной системе, а именно, к такой штуке как thread scheduler. Как может быть понятно из названия, он заведует подобными манипуляциями с потоками. Но, для JVM так же важно вовремя пробудить поток, так как изначально в методе sleep был указан интервал. Что бы иметь такую возможность, JVM не всегда использует методы самой операционной системы. Так, JVM от Sun(Компания, которая разрабатывала Java до Oracle, думаю знаете), отправляла поток в специальный пул, который с некоторой периодичностью опрашивался на предмет пробуждения. Такой себе ивент. И, обычно, у каждой ОС был свой такой период вызова ивента. Для Linux - 1ms, для Windows - 10-15ms. Ну, и всё хорошо себе работало. До момента, когда в 2001 году(Это была Java 3) был обнаружен баг: Если выставлять в Thread.sleep слишком маленький интервал, системные часы Windows станут идти быстрее! Круто, да?)
Ну, баг пофиксили, методом перехвата установки интервала с ОС, на JVM, теперь она контролировала это дело и всегда устанавливала 1ms. И что бы вы думали? В 2006 году оказывается, что при фиксе первого бага, был допущен ещё один баг, в связи с которым, интервал практически никогда так и не устанавливался на 1мс. Случилось так потому, что код фикса был написан не в том dll и не учитывал некоторый интервал при работе с терминалом. Но, за всё это время(около 5 лет), разработчики не получили ни одного репорта, поэтому решили, что лучше не трогать, раз уж так работает. Но что делать, если кто-то разрабатывал программу(Судя по тому треду, Майнкрафт был одним из таких программ), которой очень важно было, что бы её потоки пробуждались строго в указанное время? К счастью, этот интервал можно было установить самому, с помощью некоторого хака. Более того, такой интервал можно было установить не per-thread, а per-program! В общем, как вы уже догадались, этим хаком и был код выше, суть которого была в том, что бы с помощью создания демона, который вечно спит, минимизировать этот самый интервал пробуждения. Таким образом, была достигнута максимальная точность, где требовались какие-либо операции со временем.