- Баллы
- 173
А это каким образом?
-
Данный раздел создан исключительно для релизов! Вопросы по лаунчеру или обвязке задавайте ТОЛЬКО в соответсвующей теме автора. Любые другие темы будут удалены, а авторы понесут наказание.
Лаунчер Пересобранная jvm.
- Тема в разделе "Веб-обвязки и лаунчеры", создана пользователем fereter, .
- Баллы
- 66
- Имя в Minecraft
- Fereter
Файл пересобранной jvm в разы меньше oracle'овского. По сравнению с остальным клиентом этот файл все равно мал. Поэтому снижение незначительное.
- Баллы
- 103
Во-первых, собрать JVM совсем уж и не сложно: поставить флаги на игнор ошибок (CFLAGS, CXXFLAGS) да make сделать. К тому же, соответствующие статьи про сборку целой JDK есть. Ну и если совсем уж долбануться, можно юзать сторонние JVM вроде всяких Jelatine, Jikes, CACAO, ...
Во-вторых, тут даже не то что смена протокола, а небольшое изменение существующих пакетов с добавлением на сервер их обработки. Потенциально ограничится "проверкой на возможность" (мы ж не хотим, чтоб игрок двигался только после получения ответа с сервака, так ведь?), своеобразной синхронизацией. Моды — добавление поддержки по мере необходимости. А всякие проблемы вида "какой игрок быстрее какого убил" — на это на хабре изрядно статей в стиле "мультиплеер в играх".
В-третьих, почему корпорации должны двигать миром? MinecraftForge, такой глючный, разве под пару серверов существует? Можно ж сделать публичный такой патч, выложить на github/gitlab/mercury-реп/любую_иную и пусть мир помогает как в случае оперативного патчинга читов под minetest_game. Естественно, надо при этом рамки держать: нельзя допустить, чтоб патч превратился в очередной клон майна, с неевклидовой геометрией (Лобачевского?), где великий нейромозг Думатель управляет всеми вычислениями.
- Баллы
- 103
Смею заметить, что, например, CACAO дефолтным бинарником весит около 1 мега, при этом майн работает вполне нормально без каких-либо проблем. Так что те, кому надо, могут и без патча сократить кол-во места и ускорить запуск/работу с памятью/прочее выбрав подходящую JVM, если захотят что-то вместо HotSpot.
Лично я считаю, что малый размер нативного кода JVM — не такое уж и преимущество на фоне целой орды решений, которые мало кто предпочитает видеть. Надо было бы — активно юзали, но нет, достаточно всем обычной сборки от Oracle.
- Баллы
- 173
Однако, надо понимать, что Oracle Java и OpenJDK - две разных джавы. На дисковую нагрузку размер бинарника никак не влияет: библиотека отображается в память всего один раз - при загрузке - и больше к диску обращений нет.
Кроме того, интересует другое - если OpenJDK весит в 4 раза меньше, возникает вопрос - а чего же там нет, что есть в версии от Oracle? Возможно, нет каких-то оптимизаций JIT'a? Или используются более простые и прямолинейные алгоритмы? Какую именно полезную нагрузку мы теряем, заменив Oracle на OpenJDK? Вот что должно интересовать в первую очередь, а не размер, который ни на что не влияет.
Даже сам факт смешивания jvm.dll из OpenJDK с окружением Oracle вызывает вопросы - уверен, что ничего не сломается? Уверен, что твоя версия jvm.dll совместима с версией у конечного пользователя? Какие сайд-эффекты могут возникнуть?
Тебе не кажется, что уже с первого пункта начинаются костыли? Например, за игнор ошибок надо бить по рукам.
Можно сделать всё, если это целесообразно. Пока целесообразность такого античита сомнительна. Сейчас @fereter учтёт все замечания, сделает нормальный билд JVM с адекватными проверками, оттестит на разных версиях, чтобы не было вопросов - и его либу поставят себе на сервера сотни человек, защитившись прямо сейчас на достаточном уровне. Ты же предлагаешь ухнуть неизвестное количество часов на сомнительный проект, который, возможно, взлетит, а возможно, остановится на половине пути из-за отсутствующей мотивации участников или непреодолимых проблем с совместимостью.
Если найдёшь людей, поднимешь проект, будешь его поддерживать, обновлять и, главное, доведёшь до конца - you're welcome, а пока это только мысли вслух, которые здесь высказывались уже несколько десятков раз и никуда дальше "да, надо делать" не ушедших.
- Баллы
- 103
Можно заметить 2 вещи:
1. Oracle JDK и OpenJDK — почти одно и то же, в первом всего лишь чуть-чуть закрытого кода и просто иная лицензия (в основном на ересь вроде шрифтов) (а так двоичная совместимость практически 100%). Особенно при Java 11 различий практически нет.
2. На самом деле дефолтные бинарники весят практически одинаково (имею OpenJDK 6—13: 16 мегов для нативщины есть норма), а малый размер конкретного — лишь особенность сборки.
Тебе не кажется, что собирать OpenJDK 8, которая уже почти не поддерживается (патчи из новых версий приходят вот ну очень редко) — довольно странно? Увы, но код у OpenJDK оставляет желать лучшего: игнор ошибок сборки неизбежен, ибо причина в разных версий компилятора (под одним легально одно, под одним другое, а система сборки говорит "пусть все предупреждения будут считаться ошибками"). Бить по рукам надо тех тогда уж, кто в таком виде OpenJDK держит.
Извиняюсь, но я люблю Haskell и матан.
Признаю, то всего лишь "мысли вслух", но мысли по-моему хорошие.
- Баллы
- 173
Однако, разница в 4 раза весьма солидная. Интересно понять, откуда она взялась, если бинарная совместимость почти под 100%.
Но и билдится джава в msvc2010, на то время восьмая джава была весьма актуальна и проблем со сборкой быть не должно.
Категорически согласен. Привязываться к конкретной версии компилятора - свинство. И ещё большее свинство - завязывать на легаси-компиляторы актуальные версии джавы. 2019й год, собираем тулсетами десятилетней давности! Так победим!
Мысли-то хорошие, но из разряда идей они так и не выйдут. Как коммунизм. Говорят, что его надо строить (как? из чего? и где?), но никто не строит.
- Баллы
- 103
Может быть, интринсики сожрались какие-то, может быть, еще что-то. Может быть, оптимизация хорошо сработала (без режима дебага ж собрано). CACAO под Java 6 выдавал при этом очень даже неплохие результаты, хоть и весит всего ничего.
Это уж смотря чем билдить. Если билдить через GCC под целевую платформу, то на новых версиях новые предупреждения и сообщения об ошибках, ибо осознание проблем кода не стоит на месте.
Во всяком случае, эти мысли за истину как труды Маркса или Аристотеля не принимаются. Были схоластики, принимались труды Аристотеля за истину (например, его Органон), а в итоге имеем современную математическую логику с гильбертовской аксиоматикой для логики высказываний. Были коммунисты, принимались труды Маркса за истину, творились грязные дела во имя светлого коммунизма, основываясь на введенной Сталиным логике по модус поненс, а в итоге имеем рухнувший СССР и распространение логики по модус толленс.
- Баллы
- 66
- Имя в Minecraft
- Fereter
Не думал, что сжатие бинарников upx'ом откроект холивар на тему бинарной совместимости. Собранный бинарник весит почти столько же, сколько и oracle'овый. Перед публикацией он сжимается upx'ом с флагом на максимальную степень сжатия. Это нужно для того, чтобы отвадить мамкиных реверсеров искать места для патчей, не сняв upx. На скорость исполнения кода upx не влияет, ибо протектером не является.
- Баллы
- 103
Влияет тем, что во время запуска выделяется память и туда распаковывается сжатое. Что есть оверхэд в виде более долгого запуска.
- Баллы
- 173
Пару лет назад имел опыт сборки только девятой джавы в msvc2010 и пробовал завести на vs2017, патчил make, что-то частично завелось, но собрать так и не получилось. Под линукс, думаю, всё гораздо проще...
А это правильно. Независимо от содержания идей и господствующей логики, всегда полезно сомневаться и пересматривать взгляды. Рациональное зерно в идее серверных античитов, бесспорно, есть - вопрос лишь в том, как вырастить из этого зерна готовый качественный продукт.
А ларчик просто открывался. Однако, вопрос о том, действительно ли твой билд jvm.dll совместим с любым билдом у пользователя, остаётся открытым. Ты писал о проблемах с 1.6.4 - кто виноват и что делать? Какова вероятность, что такие проблемы неожиданно вылезут на других версиях или с какими-нибудь модами?
upx -d jvm.dll
Узнать тип упаковщика не составляет труда. Кроме того, возможны проблемы с антивирусами - они не доверяют упакованным неподписанным бинарникам.
Кстати, не всегда. Если бинарник большой, а диск медленный, упаковка может даже ускорить запуск.
- Баллы
- 66
- Имя в Minecraft
- Fereter
Во-первых, по сравнению с загрузкой minecraft. Распаковка почти мгновенна.
Во-вторых, с пакером запускается быстрее, так как меньше читается с медленного диска.
- Баллы
- 103
Для второго есть результаты замеров? Или же принять за плацебо?
- Баллы
- 173
И опять же, не всегда. Например, у меня m.2 ssd и 3.5 гигабайта в секунду на чтение. Уверен, что распаковка будет быстрее, чем чтение?
- Баллы
- 66
- Имя в Minecraft
- Fereter
Я рад конструктивной критике. Я уже принял к сведению отсутствие проверок стак трейса и бесполезность проверок классов по черным спискам имен. Я собираюсь выложить тесты и sashok v3 лаунчер с установленной пересобранной jvm для того, чтобы люди могли сами пощупать.
Пока из тестов только то, что ForgeOptiFine 1.7.10 в tlauncher без модов, что с защитой, что без запускаются за 13 секунд.
Пока из тестов только то, что ForgeOptiFine 1.7.10 в tlauncher без модов, что с защитой, что без запускаются за 13 секунд.
- Баллы
- 173
И опять же, абстрактные "13 секунд" - это сферический конь в вакууме. Много это или мало? Когда публикаешь сравнения, пиши относительные результаты: было -> стало. Потому что 13 секунд на Pentium 4 с полудохлым IDE-HDD - это космос. А на i9-9900k с m.2 - черепаха.
А вообще, будь у тебя хоть тысяча строк в блэклисте, сомневаюсь, что ты заметил бы разницу в запуске. Аналогично, не заметил бы влияния и каких-нибудь квадратичных или кубических алгоритмов, будь они у тебя в защите - современные процессоры настолько быстрые, что проглотят их и не подавятся. Секундой больше, секундой меньше - в пределах статистической погрешности. Но это не значит, что стоит наплевательски относиться к алгоритмам. Стоит количеству данных увеличиться хотя бы в 10 раз - процессор захлебнётся. Там, где можно оптимизировать - оптимизируй. Можешь воткнуть хэшмап - воткни. Не можешь - юзай дерево. Логарифмы лучше линейных переборов. Не можешь дерево - ну лааааадно, так и быть, перебирай по элементам, потому что не всё можно оптимизировать. Но это не твой случай.
Последнее редактирование:
- Баллы
- 103
Хорошим тестом будет сравнить время запуска для класса с пустым main, раз уж грубые замеры времени запуска клиента ощутимой разницы не показывают (хотя бы для полноты замеров). Так получится чище и гораздо более сравнимо.
Актуальность:
Например, пусть в одном случае pinta запускается 1 секунду, а в другом 0.1 секунды.
Независимо от того, виноват ли dbus или любая другая тварь кроме собственно pinta, в первом случае по предубеждению pinta мне будет казаться тяжеловеснее, чем во втором.
Последнее редактирование:
- Баллы
- 173
В общем, это всё придирки и мелочи.
@fereter, ты красавчик, что занялся защитой в джаве, но с текущим билдом разобрались, надо двигаться дальше.
Первое, что тебе надо сделать - полностью вырезать JVMTI. Насколько знаю, он отключается каким-то аргументом при билде. Второй шаг - шифрование классов: *.class-файлики передаются на вход зашифрованными, JVM их расшифровывает и запускает. Потребуется зашифровать все классы клиента и самой джавы, для этого напиши утилитку или скрипт, на вход которым передавай, например, путь к папке с клиентом, на выходе - отдельная папка с зашифрованными файлами. Это не позволит запускать чужие классы by-design, т.к. джава их просто не поймёт: после её внутренней попытки их расшифровать получит мусор.
@fereter, ты красавчик, что занялся защитой в джаве, но с текущим билдом разобрались, надо двигаться дальше.
Первое, что тебе надо сделать - полностью вырезать JVMTI. Насколько знаю, он отключается каким-то аргументом при билде. Второй шаг - шифрование классов: *.class-файлики передаются на вход зашифрованными, JVM их расшифровывает и запускает. Потребуется зашифровать все классы клиента и самой джавы, для этого напиши утилитку или скрипт, на вход которым передавай, например, путь к папке с клиентом, на выходе - отдельная папка с зашифрованными файлами. Это не позволит запускать чужие классы by-design, т.к. джава их просто не поймёт: после её внутренней попытки их расшифровать получит мусор.
- Баллы
- 173
Именно поэтому все замеры производительности - имхо - бессмысленны. Слишком много факторов влияют на запуск - и операционка вносит свой вклад, и процессор каждый раз чуть по-разному будет работать, а вот кто-то к диску пошёл стучать, пока он стоит с секундомером. Чтобы реально оценить влияние его патчей, надо прогнать миллионы классов подряд через его проверки - где бы ещё найти такие приложения. А на одном классе бОльшее влияние будет оказывать окружение.
А замерить влияние распаковщика и вовсе проблематично - что считать точками начала и конца отсчёта? Вызов CreateProcess и срабатывание какого-нибудь глобального мьютекса в main'e? Тоже не годится.