Microsoft будет на конференции JavaOne

Копирование должно быть не тупое, а компактифицирующее.

Маленькие - 8-16 байт. И их очень много, живут очень недолго, буквально, выделенное 4-5 выделений назад уже становится ненужным (ну, все уже догадались - это graph reduction).

А пулы объектов применять не пробовали ?

>Итак, я даю тебе задачу, типичную и для Си, и для Java. Если ты сможешь при всей своей опупевшей наглости получить на Java производительность выше, чем у моего решения на Си - то это войдёт в историю ЛОРа, а я публично покаюсь за все наезды на Java, какие только были.

Это чудо просто перепутал С и С++. Распространённое заблуждение среди ламеров.

Собственно, про пул объектов уже сказали чуть выше. Посмотри в сторону Javolution - они там как раз эту идею и продвигают.
Хотя, вообще говоря, я не уверен, что для расчетных задач java самое то.
Продуктивнее будет наверное на фортране написать, а если производителльность распределения памяти волнует, то и от языков с GC возможно стоит отказаться.

>>Да не надо сравнивать количество библиотек и обученных обезьянок.
Надо, еще как надо. Для меня программирование это работа, за которую заказчик платит деньги. И моя задача, реализовть систему самым эффективным способом. Я не могу искать программистов с экзотичскими для отрасли скиллами и повязать на них проект - заказчик то хочет минимизировать TCO в том числе, и риски.
>>Надо задаться вопросом, почему барашки из Sun не смогли сделать так же?
Я уже говорил, что реализаций J2SE больше одной штуки. Вы пробовали другие ? Что вам, на SUN свет клином сошелся?
Возьмем реализацию от IBM. Вы тоже заведомо считаете их разработчиков "барашками"? К сведению - эта корпорация уже 7 лет занимает первое в мире место по количеству получаемых патентов в год. Их R&D один из самых мощных в мире.
Вот, дернул первую же ссылку в гугле по словам "ibm java gc"
Вам нужен компанифицирующий GC - пожалуйста
"Fine-tuning Java garbage collection performance" (http://www-106.ibm.com/developerworks/ibm/library/i-gctroub/)

IBM implementation uses a garbage collection algorithm called mark-sweep-compact (MSC), which is named after three distinct phases.

Mark: All the objects that are "reachable," or alive, are marked. This phase starts off by locating "roots," such as objects on thread stacks, Java Native Interface (JNI) local and global references, and so on, and following each reference recursively until all references are marked.

Sweep: All the objects that were allocated but are not marked anymore are swept away, and the space used by them is reclaimed.

Compact: Holes or fragments in the heap are removed by moving the live objects together in the heap.

>>это сайт у тебя тоже тормозит ?
> в линксе? нет =)
а тоже java, значит не стоит так категорично
> limeware, azureus, читалку книг
ИМХО, для такого класса программ java (да вобщем и все VM языки) не очень подходит, хотя есть надежды на gcj.

Не канает. Это ж узлы графа...

Какая на фиг рассчётная задача? Это компилятор!

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

Про качество IBM JRE знаю. Увы - привязан к Sun, тут уж, блин, требование заказчика.

>И их очень много, живут очень недолго, буквально, выделенное 4-5 выделений назад уже становится ненужным

Если они живут очень недолго (4-5 выделений), то их не может быть очень много одновременно. Имхо, пул как раз для таких ситуаций.

Не буду настаивать, но всё-таки посмотрите, может поможет: http://javolution.org/api/javolution/realtime/package-summary.html#OVERVIEW

Да нельзя предсказать, какой из них останется жить. Тысяча сдохнет через 5 выделений, а 1-2 останутся навечно.

P.S. Дотюнил таки до 5% GC, но только ценой увеличения требований к памяти в 20 раз. Даже не смешно. :(

Да, и я не могу их вручную возвращать в пул. Для тех объектов, которые имеют предсказуемое время жизни, я и так пулы использую, но самый мерзкий и многочисленный объект - узел графа, непредсказуем абсолютно. Тут разве что только пул с собственным GC писать...

Скажите, а вот это решение http://javolution.org/api/javolution/realtime/package-summary.html#FAQ-2 Вам не подходит?

>Тут разве что только пул с собственным GC писать...

Не удивительно. Мне кажется, в случае C++ многократный вызов new/delete съедал бы таже слишком много времени. Любая задача, требующая эффективного управления памятью, может потребовать написания собственного менеджера.