1. Добавить памяти. Сервера с объемом памяти в 256-512 Gb уже не есть что-то удивительное и хайсечное. AFAIK
2. Как другой вариант, искать DOM-парсеры с оптимизацией по памяти. Чудес не бывает, но вполне возможно, нагрузка на память может быть в несколько раз (думаю до десятка) меньше, чем у "обычных" стиральных порошков парсеров типа халан/херсер.

Сколько памяти на сервера, как много юзеров, какой GC в JVM, кто нибудь профилировал/настраивал JVM.

Не хочется платить за железо (в облаке, не в облаке) - пусть платят программистам за оптимизацию

AFAIK есть DOM-парсеры оптимизированные по памяти. В живую с такими не работал, но читал. Думаю до десятка раз по сравнению с классическими разница вполне может быть.

Тут зависит от исходного ТЗ (что за файлы, что нужно делать), возможного железа (в сколько памяти нужно умешаться), какая должна быть производительность, сколько запросов/юзеров нужно обработать. Сколько времени выделяется программистам/админам.

Хочется автору pandas и dask - в общем-то, думаю проблем даже их прикрутить к JVM особых нет. Но что такое pandas и dask и что у них общего с XML/XSLT лично я не знаю ))).

1. Есть еще VTD-XML Parsing (Virtual Token Descriptor for XML).

2. Одна из первых же попавшихся статей в I-net'е от 2010 года. Представление DOM в виде xDB на диске. Как я понимаю, програмное API для таких реализаций то-же самое. Т.е. DOM, но хранение оптимизировано с точки зрения потребления памяти.

Что то более новое с ходу не нашлось, но в свое время попадалось. Т.ч. такая реализация не одна, нужно искать, смотреть.

https://www.balisage.net/Proceedings/vol5/html/Probst01/BalisageVol5-Probst01.html