Самым простым фиксом (хотя, возможно, и не самым правильным), как мне видится, будет добавление проверки на достижение минимального нормализованного числа в цикле коррекции в sun.misc.FloatingDecimal.doubleValue().
Проверил — работает.
Так что, кто хочет, может обезопасить себя от DoS'ов с помощью этого патча.
Либо добавлять в bootclasspath: java -Xbootclasspath/p:parseDoubleFix.jar, либо просто заменить соответствующий .class файл в rt.jar на прилагаемый в патче.
Про округление: помимо описанного способа округления, используемого по умолчанию, стандарт IEEE 754-2008 предусматривает еще 4 режима округления: в сторону 0, +inf, -inf и до ближайшего в сторону 0.
Также стандарт определяет два типа NaN: Quiet и Signaling. Первый молча передает значение NaN в последующие вычисления, в то время как операции над вторым приводят к исключению.
Про денормализованные числа полезно знать, что работа с ними, даже если она реализована в железе, как правило, выполняется гораздо медленнее (в десятки раз), чем с нормализованными числами. Поэтому в приложениях, нечувствительных к точности, но где важно быстродействие (3D графика, обработка сигналов), зачастую используется режим flush-to-zero. Многие FPU такой режим поддерживают аппаратно.
Если учесть, что основная (оплачиваемая) работа была связана с разработкой open source проектов, то во многих.
Это как писать JVM, работая в Sun Microsystems, или разрабатывать Chromium, работая в Google.
Нет, в релизе JDK7 этого точно не будет. Вероятно, в одном из последующих апдейтов.
Сейчас JVM ничего особо крупного в native heap не сохраняет (разве что CodeCache), поэтому и средств контроля не предоставляет. Когда туда перекочуют метаданные, будет и способ отслеживать через JMX API.
Проблема с кончающимся PermGen довольно популярная. Чтобы решить ее раз и навсегда, сейчас идет работа по ликвидации PermGen вовсе. Метаданные классов будут размещаться в native heap (проще говоря, в памяти, выделяемой malloc'ом).
Разумеется. Я про электричество, потребляемое процессором непосредственно на обработку графики, не про подсветку дисплея :)
Так все-таки, какие вы предлагали альтернативы алгоритмам заливки, тайлинга, двойной буферизации, наконец, растеризации шрифтов, сложность которых будет о-малым от dpi^2 и по памяти, и по количеству операций? Мне вдвойне интересно, поскольку одно время наша команда в Sun Microsystems занималась оптимизацией графики внутри Java ME платформы, и приходилось не раз сталкиваться с тем, что при увеличении разрешения дисплея, скажем 240x320 -> 480x640, стандартные алгоритмы начинали работать в 4 раза медленнее или занимать в 4 раза больше памяти. Поэтому приходилось прибегать к компромиссам и всяким трюкам вроде наборов тайлов разного размера, компиляции шрифтов и т.п.
Почему понадобится в 10 раз больше памяти, вполне очевидно. Любая векторная графика, прежде чем попадет на экран монитора, превращается в bitmap (заметьте, кстати, слово «растеризация» в заголовке). А чтобы обработать больший объем информации, понятно, нужны большие трудозатраты. Ни разу не видели, как какая-нибудь 3D-игруха, казалось бы, при незначительном увеличении разрешения, начинает значительно подтормаживать?
Лучше объясните, почему думаете, что не понадобится?
Очень интересная статья, но замечание про то, что майкрософтовская растеризация шрифтов тормозит технический прогресс, ей-богу, посмешило. Вообще-то, при увеличении разрешения с 96 dpi до 300 dpi, число пикселов на экране возрастет в 10 раз, а, значит, для хранения и обработки изображения понадобится в 10 раз больше памяти и в 10 раз больше вычислительных мощностей. Полагаю, решить эту задачу будет посложнее, чем изменить алгоритм растеризации.
Реверс-инжиниринг — это, безусловно, интересно, но в заголовке лучше уточнить, что речь идет о Java ME, написать «инжиниринг» через «и», и, наконец, никогда не переводить «Reflection» в программировании как «Отражение». Для этого есть правильный, подходящий по смыслу, термин Рефлексия, на который Вам уже указали выше.
Не считаете же Вы в самом деле, что целью правонарушителя была информационная безопасность ваших серверов (как в случае с DDoS)? По-моему, вполне очевидно, что в данном случае объектом правонарушения был порядок распространения рекламной информации, и поэтому доводы о нарушении работы серверов выглядят притянутыми за уши (в конце концов, сервера так были настроены).
Ладно, речь не об этом. Я хотел сказать, что ответы МВД вполне предсказуемы и в данной истории они малосодержательны. Интересней было бы увидеть официальный ответ ФАС. Но как раз этого, как я понял из поста, и не было, поскольку не было и официальной жалобы в форме бумажного письма, да?
Вот, общаться с МВД и написать кучу заявлений Вам было не лень, а найти в Интернете за пару минут, Закон о Рекламе и прочитать самому ст.18, 33 и 38 было лень?
Сэкономили бы пару месяцев и узнали бы, что рассылка спама запрещается Законом о Рекламе, что контроль за соблюдением Закона осуществляется Антимонопольным органом, а ответственность за его нарушение предусмотрена ст.14.3 КоАП.
Ну, если мы говорим о фиксе в Explorer — тогда, конечно, просто. Если же о фиксе имплементации SMB в Vista, то все это драйвер, по идее, должен делать. Объем запоминаемых данных навскидку порядка 128 * sizeof(_WIN32_FIND_DATAW) ~= 74K, немало. И надо запоминать каждый раз, мы ж не знаем наперед, встретим ли ошибку.
Или вы предлагаете перечитывать в случае ошибки сначала быстрым способом, потом медленным? Хм. Во-первых, это может быть слишком долго. А, во-вторых, ненадежно. Например, сначала мы прочитали файлы с 1 по 127. На 128 получили ошибку. Перечитываем быстрым способом, получаем файлы 1, 3-128 (2й в это время удален), пропускаем их. Перечитываем медленным способом, выдаем пользователю файлы 129-500. 128-й теряется.
Блоков нет. Перемотки тоже нет. Есть API вида FindFirstFile/FindNextFile. В какой-то момент FindNext возвращает ошибку.
Запоминать файлы — не вариант, потому что придется запоминать уйму лишних данных на уровне драйвера на каждый запрос, а это очень накладно. Не запоминать — тоже не вариант, потому что альтернативный способ не обязан возвращать файлы в том же порядке, да и содержимое каталога может запросто измениться.
Креативный вариант: встретив данный код ошибки, выдавать клиенту дополнительный псевдоэлемент (каталог) типа «Show all files...»
Зайдя в него, пользователь будет получать полный список, т.к. система, встретив в пути этот псевдокаталог, его уберет и будет использовать медленный запрос.
Дополнительно можно воспользоваться 3-м способом (запоминать сервер и использовать в следующий раз другой тип запроса).
Проверил — работает.
Так что, кто хочет, может обезопасить себя от DoS'ов с помощью этого патча.
Либо добавлять в bootclasspath: java -Xbootclasspath/p:parseDoubleFix.jar, либо просто заменить соответствующий .class файл в rt.jar на прилагаемый в патче.
Также стандарт определяет два типа NaN: Quiet и Signaling. Первый молча передает значение NaN в последующие вычисления, в то время как операции над вторым приводят к исключению.
Про денормализованные числа полезно знать, что работа с ними, даже если она реализована в железе, как правило, выполняется гораздо медленнее (в десятки раз), чем с нормализованными числами. Поэтому в приложениях, нечувствительных к точности, но где важно быстродействие (3D графика, обработка сигналов), зачастую используется режим flush-to-zero. Многие FPU такой режим поддерживают аппаратно.
Это так, небольшие дополнения. Статья суперская!
Это как писать JVM, работая в Sun Microsystems, или разрабатывать Chromium, работая в Google.
Сейчас JVM ничего особо крупного в native heap не сохраняет (разве что CodeCache), поэтому и средств контроля не предоставляет. Когда туда перекочуют метаданные, будет и способ отслеживать через JMX API.
Да, про PermGen автор ерунду написал.
Так все-таки, какие вы предлагали альтернативы алгоритмам заливки, тайлинга, двойной буферизации, наконец, растеризации шрифтов, сложность которых будет о-малым от dpi^2 и по памяти, и по количеству операций? Мне вдвойне интересно, поскольку одно время наша команда в Sun Microsystems занималась оптимизацией графики внутри Java ME платформы, и приходилось не раз сталкиваться с тем, что при увеличении разрешения дисплея, скажем 240x320 -> 480x640, стандартные алгоритмы начинали работать в 4 раза медленнее или занимать в 4 раза больше памяти. Поэтому приходилось прибегать к компромиссам и всяким трюкам вроде наборов тайлов разного размера, компиляции шрифтов и т.п.
Лучше объясните, почему думаете, что не понадобится?
Ладно, речь не об этом. Я хотел сказать, что ответы МВД вполне предсказуемы и в данной истории они малосодержательны. Интересней было бы увидеть официальный ответ ФАС. Но как раз этого, как я понял из поста, и не было, поскольку не было и официальной жалобы в форме бумажного письма, да?
Сэкономили бы пару месяцев и узнали бы, что рассылка спама запрещается Законом о Рекламе, что контроль за соблюдением Закона осуществляется Антимонопольным органом, а ответственность за его нарушение предусмотрена ст.14.3 КоАП.
Или вы предлагаете перечитывать в случае ошибки сначала быстрым способом, потом медленным? Хм. Во-первых, это может быть слишком долго. А, во-вторых, ненадежно. Например, сначала мы прочитали файлы с 1 по 127. На 128 получили ошибку. Перечитываем быстрым способом, получаем файлы 1, 3-128 (2й в это время удален), пропускаем их. Перечитываем медленным способом, выдаем пользователю файлы 129-500. 128-й теряется.
Запоминать файлы — не вариант, потому что придется запоминать уйму лишних данных на уровне драйвера на каждый запрос, а это очень накладно. Не запоминать — тоже не вариант, потому что альтернативный способ не обязан возвращать файлы в том же порядке, да и содержимое каталога может запросто измениться.
Зайдя в него, пользователь будет получать полный список, т.к. система, встретив в пути этот псевдокаталог, его уберет и будет использовать медленный запрос.
Дополнительно можно воспользоваться 3-м способом (запоминать сервер и использовать в следующий раз другой тип запроса).