большое кол-во мелких объектов и сборщик мусора
Есть такая задача - требуется держать в памяти около 100 млн. мелких долгоживущих объектов размером от 9 до 20 байт. Если держать их как объекты, это приводит к большому перерасходу памяти для контрольных данных объекта, и, похоже, к огромному расходу cpu на сборщика мусора, котоомую хоть и редко, но приходится просматривать всю кучу.
Как принято культурно решать такие вопросы? У меня пока есть два варианта.
1. Получить byte array под это все дело и работать с ним как с блоком памяти. Из плюсов, что наверняка нет каких-либо побочных эффектов.
2. Засунуть всю работу с ними в jni-шные функции, оттуда резервировать через malloc. Из плюсов, получается и выигрыш в скорости. Но есть опасение, что чревато разными глюками.
upd: Это статистика. В одной структуре строка символов длиной от 0 до 11, и два 32bit числа. Мог бы уменьшить их число до нескольких десятков тысяч, но я наоборот решаю задачу сокращения выч. сложности n4 до n2 за счет памяти. Вопрос не по алгоритму, а по техническим особенностям работы в джаве.
Как принято культурно решать такие вопросы? У меня пока есть два варианта.
1. Получить byte array под это все дело и работать с ним как с блоком памяти. Из плюсов, что наверняка нет каких-либо побочных эффектов.
2. Засунуть всю работу с ними в jni-шные функции, оттуда резервировать через malloc. Из плюсов, получается и выигрыш в скорости. Но есть опасение, что чревато разными глюками.
upd: Это статистика. В одной структуре строка символов длиной от 0 до 11, и два 32bit числа. Мог бы уменьшить их число до нескольких десятков тысяч, но я наоборот решаю задачу сокращения выч. сложности n4 до n2 за счет памяти. Вопрос не по алгоритму, а по техническим особенностям работы в джаве.
