Что такое дампить игры

Что такое дампить игры

В связи с тем, что не у всех есть высокоскоростной интернет, а через диал-ап скачивание игры влетает в копеечку,
я решил, что целесообразно написать сей фак по созданию ISO образов игр.

Нам потребуется программа Fastloader и, собственно, UMD диск, дамп/образ которого мы собираемся делать.

Скачать: Fastloader_v0.7.rar ( 628.82 КБ )

1). Убедившись в том, что UMD диск находится в приводе, запускаем программу.
2). В меню выбираем пункт -Dump inserted UMD! – далее будет шутка, которую вы непременно оцените (!)
3). Существует 2 способа дампа диска: с разбиением на части и без разбиения соответственно.

Начну со 2-го способа (он для тех, у кого карта больше 1ГБ):

Клавишами влево/вправо выбираем No splitting (dig. left/right to change) и нажимаем «Х».
Дамп начался. После его завершения заходим в папку ISO на PSP, находим там наш файл My latest dump и добавляем ему расширение ISO. Всё.

А теперь рассмотрим способ с разбиением на части:

Процесс снятия дампа завершён. На диске С у нас есть три файла My latest dump (Part 1),My latest dump (Part 2) и My latest dump (Part 3).
Переименовываем наши файлы в Part1, Part2 и Part3, так легче.
Теперь будем их склеивать. В меню «ПУСК» выбираем команду «ВЫПОЛНИТЬ» и прописываем команду cmd

Теперь копируем эту строчу: C:\Documents and Settings\Sergey>copy /b part1+part2+part3 gtalcs.iso

Склеивание началось. По окончании забираете вашу исошку из этой же папки.

Так же хочу отметить, что дампы игр весят очень много, поэтому советую скачать программу PSP ISO Compressor, позволяющую
вам сжать вашу ISO-шку более чем в 2 раза (допустим переделав её в cso), тем самым экономя место на вашей карте.

Скачать: PSP_ISO_Compressor_v1.4.rar ( 349.31 КБ )

Как применять этот способ:

UMD Dax Dumper как альтернатива Fastloader

Специально для обладателей кастом прошивок. Скачиваем программу UMD Dax Dumper и наслаждаемся дампами игр!
Принцип действия такой же как и в Fastloader-e, т.ч. разбираемся.

Создание образов по средствам VSH Menu :

1). Вставляем UMD диск в привод PSP и подключаем пристаку к ПК по USB кабелю
2). Нажимаем клавишу SELECT
3). В пункте «USB Device» выставляем «UMD Disk» и закрываем меню нажатием клавиши SELECT или выбираем «EXIT»
4). На приставке запускаем «Соединение USB» в настройках
5). Копируем образ из открывшейся папки на ваш ПК
6). Переносим готовый образ на карту памяти в папку ms0:/ISO/

Источник

Что такое дампить игры

Информация о NoNpDrm ( Coming Soon )

Находите Homebrew, загружайте напрямую в консоль и пользуйтесь.
Все ограничено только размером вашей карты памяти

Важно:
— Перед запуском убедитесь, что вы подключены к WiFi
— Первый запуск займет около двух минут

Скоро:
— Поддержка плагинов
— Проверка обновлений для приложений
— И много другого

Список всех Homebrew для PS VITA: GBATemp

Если запустишь эмулятор увидишь ux0:/data/Snes9xVITA/
Хотя там можно по папкам лазить так что не принципиально. А вот игры кидать не в архиве

Для nes сразу три эмулятора от RetroArch

Unbe, на вите в виде хомки есть продолжение Исака.

Rand0rnV, никогда я думаю.Придумай причину зачем это надо, кроме я уже купил Виту и смартфон мне теперь не светит? 🙂 Уже давно есть решения для конфортной игры на андроиде. Тут и готовые устройства со стиками и кнопками и блютуз джойстики в которые можно вставить любой аппарат и играть и даже возможность подключить обычные геймпады к телефону на андроиде.

Вообще, серия Castlevania, она на голову превосходит перечисленное тобой как по сложности, так и по количеству контента/размеру игрового мира. Другое дело, что на Вите её нету. Вид сбоку, как ты и хочешь.
На вите можешь попробовать Shiren the Wanderer: The Tower of Fortune and the Dice of Fate, вид сверху. Но она ещё сложнее, рандомнее. Она «пошаговая», то есть когда ты делаешь какое-то действие, его делает и что угодно вокруг тебя. Думаю, если когда-нибудь играл в рогалики, то понимаешь о чём я.

Unbe,
Bastion, Super Meat Boy, Hotline Miami 1/2

Salt and Sanctuary вроде еще не вышла для виты.

Вот кстати да, хорошо бы пацана мясного, вроде нету дампов нигде

Интересно, возможен ли будет в будущем перенос перевода с ios и steam версий игры для виты. Интересные проекты, такие как Star Ocean, I am Setsuna и Chaos Rings 3 получили свою локализацию, но версии для виты остались без внимания.

Отлично! Скорее бы на Vita. На ПК играли, как оно?
UPD. Почитал обзоры, капец я ее жду на Виту теперь..

Источник

Всё, что вы хотели знать о стек-трейсах и хип-дампах. Часть 2

Всё, что вы хотели знать о стек-трейсах и хип-дампах. Часть 1
Перед вами вторая часть расшифровки доклада Андрея Паньгина aka apangin из Одноклассников с одного из JUG’ов (допиленная и расширенная версия его доклада с JPoint 2016). В этот раз мы закончим разговор о стек-трейсах, а также поговорим о дампах потоков и хип-дампах.

Раз уж мы заговорили о рекурсии, что будет, если я запущу вот такой рекурсивный метод, который никогда никуда не возвращается:

Сколько пройдет вызовов, прежде чем появится StackOverflowError (при стандартном размере стека)?
Давайте измерим:

Тот же самый код, только добавили catch StackOverflowError.
На 64-битной системе с размером стека 1 Мб результат варьируется от 22 до 35 тыс. вызовов. Почему такая большая разница? Дело в JIT: методы компилируются в фоновом потоке компилятора параллельно с исполнением java-кода. В какой-то момент (после того, как метод recursion несколько раз уже вызвался) запускается компиляция этого метода, а в это время продолжается исполнение в интерпретаторе. Как только компилятор закончит свою работу, следующий вызов перейдет в скомпилированный код.

Начиная с Java 8, у нас по умолчанию в одной VM есть 2 компилятора — «легкий» C1 и «тяжелый» C2, т.е. возможна ситуация, когда у нас на стеке окажутся фреймы трех типов: интерпретированный, скомпилированный C1 и скомпилированный C2. Размер фрейма может сильно отличаться. У интерпретатора самые громоздкие фреймы, потому что все хранится на стеке (все аргументы, локальные переменные, указатель текущего байткода и т.д.). В скомпилированном коде многое из этого не нужно и, чем оптимальнее будет компилятор, тем меньше надо хранить на стеке. C2, к примеру, вообще не будет заводить место на стеке под локальные переменные — все распихает по регистрам, а еще и заинлайнит на один уровень.

Если тот же самый код исполнить в чисто интерпретируемом режиме с ключиком

-Xint

Результат — практически всегда 12500 (± несколько фреймов).
Теперь то же самое, но после компилятора C1.

По умолчанию на 64-битной архитектуре размер стека 1 Мб, но его можно корректировать. Эти 2 ключика — синонимы.

Thread(ThreadGroup, target, name, stackSize)

Но при создании больших стеков нельзя забывать о том, что они занимают место в памяти и может случиться такая ситуация, что много потоков с большим размером стека приведут к out of memory:

Минимальный размер стека на 64-битной системе — примерно 228 Кб (он может меняться от версии к версии JDK). Как устроен стек и откуда складывается этот минимальный размер?

На стеке, помимо фреймов ваших Java-методов, есть еще некоторое зарезервированное пространство. Это как минимум всегда 1 красная зона (размером с 1 страницу — 4 Кб) в самой верхушке стека и несколько страниц желтой зоны.

Красная и желтая зоны нужны для проверки stack overflow. В начале обе зоны защищены от записи. Каждый Java-метод через попытку записи по адресу текущего стек-поинтера проверяет достижение красной или желтой зоны (при попытке записи операционная система генерирует исключение, которое виртуальная машина перехватывает и обрабатывает). При достижении желтой зоны она разблокируется, чтобы хватило места запустить обработчик stack overflow, и управление передается на специальный метод, который создает экземпляр StackOverflowError и передает его дальше. При попадании в красную зону возникает unrecoverable error и виртуальная машина фатально завершается.

Есть еще так называемая shadow-зона. У нее довольно странный размер: на Windows — 6 страниц, на Linux, Solaris и прочих ОС — 20 страниц. Это пространство резервируется для нативных методов внутри JDK и нужд самой виртуальной машины.

Когда я готовил презентацию, запускал свой рекурсивный тестик и на Java 8, и на Java 9. На последней я получил такой чудесный краш виртуальной машины (фрагмент вывода):

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x0000019507acb5e0, pid=9048, tid=10544
#
# JRE version: Java(TM) SE Runtime Environment (9.0+119) (build 9-ea+119)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+119, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# J 155 C2 demo4.Recursion.recursion()V (12 bytes) @ 0x0000019507acb5e0 [0x0000019507acb5e0+0x0000000000000000]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
.

Я, естественно, скачал самый последний из доступных билдов (на момент доклада это был 9.0+119), на нем эта проблема также воспроизводится.
Это очень хороший случай для анализа краш-дампа (Андрей Паньгин — Анализ аварийных дампов JVM). Тут пригодились все навыки, в частности, дизассемблирование.
Вот инструкция, которая записывает значение относительно текущего стек-поинтера. Краш произошел как раз на этой инструкции:

Instructions:
00000000: 89 84 24 00 a0 ff ff mov DWORD PTR [rsp-0x6000],eax
00000007: 55 push rbp
00000008: 48 83 ec 10 sub rsp,0x10
0000000c: 49 ba 78 71 88 8d 00 00 00 00 movabs r10,0x8d887178
00000016: 41 83 42 70 02 add DWORD PTR [r10+0x70],0x2
0000001b: e8 e0 ff ff ff call 0x00000000

Java Threads:
=>0x0000019571d71800 JavaThread «main» [_thread_in_Java, >
stack(0x0000007632e00000,0x0000007632f00000)]
0x0000007632e00ff8

Используя значение регистра RSP, можно вычислить адрес, в который мы записываем. Нужно отнять 6000 в HEX от этого адреса, получится какое-то такое значение:

Мы записываем по этому значению. Там же в краш-дампе указан диапазоны стека текущего потока:

Мы видим, что это значение попадает в конец самой первой (самой верхней) страницы этого стека, т.е. как раз в красную зону.

Действительно, есть такой баг. Я проанализировал его и нашел причину: некоторым функциям JVM не хватает на Windows доступных 6 shadow-страниц (они занимают больше при исполнении). Разработчики виртуальной машины обсчитались.
Кстати, размер этих зон можно менять ключиками JVM.

Зачем нам вообще большие стеки? Для Java EE, не иначе.
Вот одна из моих любимых картинок на эту тему.

На 2 строчки бизнес-логики порождаются сотни фреймов от различных фреймворков и application-серверов.

Стек-трейсы для измерения перформанса

Профилирование — неотъемлемая часть измерения производительности вашей системы. Все профиляторы можно разделить на 2 большие группы: семплирующие и инструментирующие.
Инструментирующий профайлер просто помечает методы: добавляет в начало какую-то сигнализацию о входе в метод, в конец — сигнализацию о выходе из него. Понятно, если мы каждый метод так проинструментируем, все это будет создавать большой overhead, хотя измерение будет довольно точным.

В продакшене чаще всего применяется иной подход — семплирующий профайлер. Он с какой-то периодичностью (10-100 раз в секунду) снимает дамп потоков и смотрит, какие треды с какими трейсами в данный момент выполняются. Методы, которые чаще всего попадают в эти стек-трейсы, и являются горячими.

Давайте посмотрим сразу на примере, как это работает. Я написал небольшую программку. Несмотря на то, что она маленькая, сходу и не скажешь, что в ней может тормозить.
Во-первых, она генерирует 2 случайные географические координаты. Потом в цикле вычисляет расстояние от случайно сгенерированной координаты до другой заданной точки (Москвы) — т.е. есть функция distanceTo, в которой много математики.
Результаты складываются в хэш-мап.

Все это в цикле много-много раз бежит:

Тут все может тормозить: и генерация случайной координаты, и измерение расстояния (тут много математики), и раскладывание по мапе. Давайте запустим профайлер и посмотрим, на что именно тут тратится время.

Возьму Java VisualVM (входит в стандартную поставку JDK — ничего проще нет), нахожу наш процесс на закладке Sampler, щелкаем CPU — начинаем измерения (дадим поработать пол минуты). Дефолтный интервал измерений — раз в 100 мс.

Чуть менее чем полностью (согласно профилятору Java VisualVM) время у нас тратится на IdentiryHashMap.put.

Если посмотреть плоскую табличку по методам, отсортировав по SelfTime:

Как будто ничего другого и не выполняется.
То же самое можно померить другими профайлерами (JProfiler, YourKit и т.п.), уверяю вас, результат будет такой же.

Неужели HashMap настолько тормозные? Нет. Просто профайлеры врут.
Устроены они при этом одинаково: с заданной периодичностью они через JMX или JVMTI вызывают метод, который получает дамп всех потоков. Например, в JVMTI есть метод GetAllStackTraces. То, что виртуальная машина говорит, они здесь суммируют и печатают.

Положа руку на сердце, это не профайлеры врут, а JVM — она дает неправильные стек-трейсы. У всех профайлеров есть одна большая проблема: стек-трейсы потоков могут быть сняты только в моменты safepoint, а это определенные точки в коде, про которые виртуальная машина знает, что поток можно безопасно остановить. И таких точек на самом деле немного: они есть внутри циклов и в точках выхода из методов. Если у вас есть большое полотно кода — той же математики; без циклов — в нем может вообще не быть safepoint, значит, это полотно никогда в стек-трейсы не попадет.

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

Также большинство профайлеров не могут отличить нативные методы, которые спят на каком-то блокирующем системном вызове. Например, при ожидании данных из сокета поток будет в состоянии RUNNABLE и профайлер будет показывать, что поток ест 100% CPU. А он не ест CPU, просто виртуальная машина не может отличить работающий нативный метод от блокирующего системного вызова.

В ОС предусмотрены возможности для профилирования нативного кода. Если говорить о Linux, там есть системный вызов setittimer, который задает таймер и с заданной периодичностью генерирует специальный сигнал ОС (SIGPROF) для профилирования. Получать его будет тот тред, который в данный момент исполняется. Нам бы хорошо уметь использовать возможности ОС и в обработчике сигнала SIGPROF собирать стек-трейсы текущего потока, даже если он не в safepoint. И в виртуальной машине HotSpot такая возможность предусмотрена. Есть недокументированный приватный API: AsyncGetCallTrace, который можно вызывать для получения текущего стека потоков не в safepoint.
Эта дырка была пропилена специально для Oracle Developer Studio. Это чуть ли не единственный профилятор, который получает честный стек-трейс.
Пока готовил этот доклад, я смотрел, а есть ли кто-то еще, кто использует эти методы. Нашел буквально 2 проекта: один — старый и уже заброшенный, а другой появился сравнительно недавно (в 2015 году) и называется honest-profiler.

API здесь довольно простой: подготавливаем место, куда будем складывать стек, и вызываем метод:

Третьим параметром этого метода является текущий контекст, который приходит к нам в signal handler.

Ссылка на мой собственный open source профайлер: https://github.com/apangin/async-profiler. Берите — пользуйтесь. Сейчас он уже в том состоянии, когда его не стыдно показать людям. Правда, сейчас он реализован только для Linux (Примечание: со времени доклада добавилась поддержка macOS).

Проверим на том же примере.
Говорим, какой процесс профилируем.

Наш pid — 3202.
Особенность моего профайлера (которую я еще ни у кого не видел) в том, что он может подключаться на лету (упомянутый honest-profiler надо обязательно запускать в качестве Java-агента при старте приложения).

Дадим несколько секунд на профилирование. Вот что получаем в результате:

В конце — плоский список методов; чуть выше — отдельно подробности (все стеки потоков). Картина кардинально отличается. Чуть ли не треть всего времени уходит на математику — вычисление расстояния. IdentityHashMap.put — вообще внизу с результатом 2% (согласно первому профайлеру он занимал 100%). А реально занимает время вычисление identityHashCode объекта. И немало времени уходит на сам put и resize. К слову, генерация случайной локации тоже не бесплатна (как минимум 12%).
Почувствуйте разницу.

Накладные расходы этого профайлера гораздо меньше. Его можно запускать хоть 1000 раз в секунду, и это будет нормально, поскольку он снимает стек-трейс только активного потока. И складывает результаты он в очень компактную структуру — он не генерирует все эти названия методов, классов. Это все вычисляется только при распечатке. А во время профилирования складываются только jmethodID (фактически, указатели на методы).

Дампы потоков

Есть много способов делать дампы потоков: из Java кода или из натива, изнутри самого процесса или снаружи.
Если говорить об анализе процесса изнутри, то есть Java API getAllStackTraces, который выдает нам массив StackTraceElement со всеми вытекающими.

Когда мы на продакшене пытались им пользоваться, для случая с 2 тысячами потоков, у каждого из которых глубина стека 50-60 фреймов, один только этот массив занимал порядка 50 Мб.
Есть похожий метод у JMX (он полезен тем, что его можно дергать удаленно). Он выдает тот же самый массив StackTraceElement, а вдобавок еще информацию о захваченных мониторах.

Если говорить о генерации стек-трейсов из самого приложения, гораздо лучше способ — JVMTI (Tool Interface) — нативный интерфейс для разработки инструментов, профилировщиков, анализаторов и т.д.

Есть метод GetAllStackTraces, который обычно используют как раз профайлеры. По сравнению с Java API у него очень компактное представление.

Преимущество метода в том, что стек-трейсы распечатает сама Java машина. Это делается с максимальной скоростью. Это все равно происходит во время safepoint, но нам не нужно создавать никаких промежуточных структур.
Альтернативный путь — утилита jstack. Она работает через механизм dynamic attach (на ней я остановлюсь подробнее).

После того как соединение по UNIX socket установлено, утилита посылает команду, и эту команду исполняет сама виртуальная машина, а ответ пересылает назад утилите по этому же сокету.

В Window все устроено несколько по-другому (не знаю, почему нельзя было сделать так же; в Windows нет разве что UNIX-сокетов, зато есть named pipes) — есть другой красивый API, который мне нравится, поэтому я не мог не упомянуть его здесь.

Начало примерно такое же — создается named pipe. Далее в Windows API есть функция WriteProcessMemory, которая может записывать некоторые данные напрямую в память чужого процесса, если у нее есть на это права. Через эту функцию создается временная вспомогательная страница памяти в адресном пространстве java-процесса, туда записывается команда, которую нужно выполнить, аргументы и название pipe, куда пойдет ответ. Еще одна не менее чудесная функция, которая позволяет внедрить в чужой процесс тред — CreateRemoteThread. Утилита jstack запускает удаленный поток — он исполняется уже в контексте процесса виртуальной машины. И в качестве аргумента этому треду передается указатель на созданную ранее область памяти, где есть вся информация о команде.

Далее все то же самое: JVM сама исполняет команду и посылает результат назад.

Плюсы такого подхода:

Виртуальная машина поддерживает следующие команды:

Это дамп тредов, дамп хипа, получение гистограммы хипа, распечатка и установка флагов виртуальной машины, исполнение команд, которые умеет исполнять утилита jcmd, и load — наверное, самая интересная команда, которая позволяет загрузить библиотеку JVMTI-агента в удаленную виртуальную машину. С помощью команды load и работает мой async профайлер (загружает свою библиотеку в удаленную JVM).

Кратко продемонстрирую, как это работает. Запущу какой-нибудь процесс, допустим, tomcat.
pid процесса — 8856.

По команде выдается тот самый дамп потока. Поскольку это не java-утилита, а С, нам не нужно тратить время на запуск Java. Утилитка очень короткая — буквально 100 строчек для Windows и для Linux. Доступно на GitHub.

Через этот механизм работает не только утилита jstack, но и утилиты jmap, jinfo и jcmd (по сути один мой jattach исполняет роль всех этих утилит).

На Linux через системный вызов PTRACE_ATTACH (на Windows есть аналогичный) полностью останавливает процесс, к которому подключаемся, замораживая его состояние. Дальше через дебажный API, который позволяет читать память с чужого процесса, утилита jstack вытаскивает все, что нужно, из удаленного JVM процесса. Далее у себя реконструирует структуры JVM и пробегает по ним, сама восстанавливает стек.

Поскольку операция PTRACE_PEEKDATA за 1 раз из чужого процесса может прочитать только 1 машинное слово, если нам нужен большой хип, придется сделать много системных вызовов (что, конечно же, очень медленно).

Для чего это нужно? Например, в ситуации, когда сервер начинает по какой-то причине тормозить и перестает справляться с потоком входящих запросов. Когда приложение детектит эту ситуацию (например, исчерпался thread pool), запускается дамп потоков, чтобы разработчик в логах мог увидеть, что же система делала в этот момент, что же именно затупило.

Мы у себя в проекте ранее использовали Java API для получения стека потоков, это было очень медленно и занимало кучу памяти. Вместо этого мы теперь собираем информацию через Dynamic Attach — есть к нему Java API, через который как раз и работает утилита jstack. Мы узнаем pid своего же процесса, подключаемся сами к себе через Dynamic Attach и заставляем виртуальную машину саму сгенерировать нам дамп.

Хип-дампы

Утилита jmap в принципе устроена так же.

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

У jmap также существует 2 режима работы: через Dynamic Attach и через Serviceability Agent (с теми же плюсами и минусами).

К счастью, есть хитрый способ, как быстро снимать дампы с мертвых или зависших процессов в forced-режиме.

Давайте покажу на примере.
У меня запущен tomcat с pid 2362. Попробуем снять jmap в forced-режиме:

Это происходит долго. Ждем пару минут и прерываем. В то же время, если я вызову gcore, core dump получаем за секунду. Занимает он 227 Мб.
Приложение дальше работает: ваши пользователи даже не заметили, что tomcat на секунду перестал принимать подключения.

Дальше jmap можно натравить на этот core-файл.

В тех случаях, когда что-то пошло плохо, хочется генерировать хип-дамп автоматически. Для этого есть опция виртуальной машины:

-XX:+HeapDumpOnOutOfMemoryError

Она полезна для самого распространенного случая — когда у вас произошло out of memory. Сборки GC можно не дождаться, лучше сразу сдампить хип для последующего анализа и рестартануть приложение.

Также можно дампить хип до и после полной сборки мусора:

Опционально можно задать путь или конкретное имя файла, куда это все будет сложено.

Интересно, что все перечисленные опции являются manageable, т.е. включать и выключать их можно прямо в рантайме, либо снаружи через команду jinfo, либо из приложения через JMX-интерфейс.

В Java 8 update 92 появились еще 2 новых опции для автоматизации хип-дампов (как раз чтобы downtime был как можно меньше):

Честно говоря, опции, конечно, полезные, но можно и без них было обходиться. Ничто не мешало задать одновременно такие 2 опции (сдампить хип на out of memory и потом прибить это же приложение):

Какие есть способы сгенерировать дамп хипа?

Это можно сделать из java, из native, изнутри процесса, снаружи процесса.
Изнутри процесса проще всего через соответствующий MXBean:

Аналогично если у вас снаружи торчит JMX remote interface, можете через него подключиться и на удаленной виртуальной машине сфорсировать дамп хипа.
Важный момент: jmap работает всегда только на локальной машине, поэтому если у вас нет возможности по ssh к продакшн-серверу подключиться, но необходимо дампить хип, единственный способ его получить — через JMX remote interface.

Быстрее и более гибко из приложения позволяет это сделать все тот же JVMTI. Есть такая замечательная функция IterateOverInstancesOfClass.

Этой функции можно сразу сказать, что нужно обойти только экземпляры какого-то конкретного класса или интерфейса. Например, вы хотите найти объекты только нужного вам типа, а хип у вас на 16 Гб.

Интересный момент, что пользоваться этой функцией нужно в два этапа. Сначала сама эта функция ничего не возвращает, но дает возможность пометить объекты, которые вы хотите потом получить. А уже затем вызовом GetObjectsWithTags можно получить отмеченные объекты в массив jobject.

Моя любимая тема — это serviceability agent — API, который есть в HotSpot. Он изначально создавался для разработчиков JDK и JVM, но нашел применение и у простых Java-программистов.

В библиотеках Java есть файлик sa-jdi.jar — это как раз API serviceability agent. Он знает все о внутренностях виртуальной машины: какие есть внутренние структуры JVM, по каким оффсетам что лежит, и есть Java API, чтобы этим всем пользоваться. В частности, можно подключиться к другому процессу VM и обойти хип другого процесса.

Давайте рассмотрим на примере.
Представьте, что вы — хакер, получили на короткое время доступ к серверу. Вы хотите получить оттуда какую-то информацию, например, приватные ключи. Но если вы будете дампить хип целиком, это очень быстро заметят, т.к. тут же сработает монитор простоя приложения. А с помощью serviceability agent можно обойти в хипе только объекты нужных классов и распечатать их.
API очень простой.

Уже заготовлен весь фреймворк (в виде класса Tool), и утилита должна просто заэкстендить этот класс и вызвать его метод execute с аргументами (даже обработка аргументов уже происходит за вас). Остается только в методе run реализовать логику.

Это все работает через механизм serviceability agent, когда отлаживаемый процесс полностью останавливается и методом чтения удаленной памяти происходит общение утилиты с Java-процессом. По окончании работы утилиты работа процесса возобновляется.
Попробуем посмотреть наш tomcat таким образом.

Через пару секунд сканирования хипа результат получен — распечатались все объекты нужного типа, которые есть в хипе.

Я, конечно, немного схитрил. Print выводит плоское описание объекта, а сам ключик внутри этого байтового массива.

Поэтому нужно еще дополнительно обойти это поле. У меня на этот случай заготовлен класс FieldPrinter, который движется по объекту и, если его имя совпадает с указанным fieldName, преобразует его в байтовый массив и распечатывает.

На выходе имеем в чистом виде private key с сервера.

У serviceability agent еще много всяких возможностей, которые получить любым другим API не получится. Например, такой экзотический случай: вам нужно обойти не все объекты, а только те, что в oldGen. Поскольку serviceability agent все знает о внутренних структурах, у него есть даже такой API. Можно получить представление хипа в удаленной Java-машине и у него получить представление именно oldGen, опять же этим итератором пройтись по всем объектам и посмотреть, если этот объект бежит только в oldGen, только в этом случае его распечатать.
В данном случае я распечатаю все строки tomcat, которые лежат в oldGen:

Лично встретиться с Андреем в Москве можно будет уже совсем скоро — 7-8 апреля на JPoint 2017. В этот раз он выступит с докладом «JVM-профайлер с чувством такта», в котором расскажет, как можно получить честные замеры производительности приложения, комбинируя несколько подходов к профилированию. Доклад будет «всего» часовой, зато в дискуссионной зоне никто не будет ограничивать вас от вопросов и горячих споров!

Кроме этого, на JPoint есть целая куча крутых докладов практически обо всем из мира Java — обзор планируемых докладов мы давали в другом посте, а просто программу конференции вы найдете на сайте мероприятия.

Источник