Здравствуйте, Gaperton, Вы писали:

G>JFYI: Динамический инлайнинг виртуальных функций на новых процах уже не даст выраженного преимущества JIT, так как мне из достоверных источников известно, что разработчики процессоров уже научились делать предвыборку и предсказания по косвенным джампам. Специально для того, чтобы понизить цену виртуального вызова. Насколько я слышал краем уха, в процах последней линейки эта фича уже есть. Они ведь тоже ориентируются на производительность реальных приложений.
Это еще в вроде бы P4 было, я про это даже сюда как-то писал. Там фича в том, что таблица предсказателя — она не бесконечная, сам предсказатель не идеальный, и сам косвенный вызов становится дешевле, но не совсем бесплатным. Так что инлайнинг помогает.

G>А для инлайна статических вызовов, раскрутки циклов, и распределения регистров (которых в x86 неприлично мало) у нормалного компилятора есть гораздо больше времени, чем у JIT. И на оптимальную кодогенерацию у него также гораздо больше времени, чем у джит. Скажем, IC++ учитывает такое количество факторов при кодогенерации, которое JIT-у в реальном времени учесть просто не под силу.
Только большую часть этих фич можно предрассчитать заранее В частности, это одна из причин почему в Java 7 вводят систему модулей, которые будут работать наподобии сборок в .NET. Модули можно будет заранее слинковать и кэшировать для них оптимизированый код.

G>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так.
Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.

C>>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.
G>Борись-не борись, а природу не обманешь. Интерпретация кода по любому на порядок тормознее выполнения native. А JIT — чем больше времени тратится на компиляцию, тем оптимальнее получается код, и тем больше выходит задержки. Хочешь учитывать факторы динамики — изволь периодически перекомпилять код.
Сейчас с приложениями на Java проблема в том, что они долго запускаются. В Java 7 это частично пофиксили — оно умеет прекомпилировать системные файлы и сохранять их в виде кэшированого исполняемого кода. Поэтому в бэтах JDK7 приложения реально "на глаз" начали запускаться как нативные.

C>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.
G>Тебе про ИЛ-2 ответили чуть ниже — справедливости ради. Почему логика была на Java, и что произошло, когда ее на С++ переписали. Кроме того, я же тебе говрю — по приложениям заметны тормоза. Я видел это на игрушке своими глазами — полигонов и объектов там было меньше, чем в аналогичных играх в native, а тормозила она больше.
Как создатель видеочата с DIVX компрессией на Java могу сказать, что больше всего проблем было с GC. Скорость вообще проблемой не была.

Ну и ИЛ-2 работал так вполне прилично, когда еще был на Java написан.

G>Можешь называть эрланговский GC тупым и тормозным, если тебе так нравится, но факт состоит в том, что в отличии от мега-умных GC Java, — это настоящий инкрементальный GC, который обеспечивает реактивность приложения достаточную для телеком применений, что ни одна другая платформа со сборкой мусора сейчас дать не способна.
Инкрементальные GC — это фигня. Они есть ВЕЗДЕ, даже JVM можно настроить, чтобы использовался только трехцветный mark&sweep. Проблема с ними в том, что мутатор (т.е. работающая программа) на Java может заполнять кучу намного быстрее, чем ее будет собирать mark&sweep. В результате приложение может вдруг получать OutOfMemory. Не веришь — возьми сложное приложение на Java и поставь только инкрементальный mark&sweep. Потом наблюдай спецэффекты.

В Erlang'е все хорошо из-за того, что объекты иммутабельны — там можно выполнять упрощенный вариант трехцветного mark&sweep.

G>В результате, на Эрланге можно делать такие штуки, как свитчи вроде AXD301, которые не смотря на тормознутость Эрланговского GC — одни из самых производительных в мире соф-свитчей, а на Java с его мегаумным GC — у тебя не получится. Это — факты, уважаемый коллега, а не эмоции или "мнения". Мне от GC нужна именно реактивность, во вторую очередь — производительность на реальных задачах, а на такой параметр как "умность" не совершенно плевать.
Я как раз сейчас с телекомом работаю. Да, там Эрланг идеально подходит — скорость не очень важна, зато важно время отклика.

Но ведь ты изначально про тормознутость говорил! А тут, как ты сам знаешь, Эрланг сливает по полной программе.

G>Для J2ME сборщики такие все из себя рилтайм, что там программерам не рекомендуют объекты шибко активно выделать, и рекомендуют выделенные объекты переиспользовать, а не оставлять их GC. А если надо отдать объект GC — то надо ручками все ссылочки занулить, чтоб бедный GC не перенапрягся. В результате, пишешь такой код, как будто никакого GC и вовсе нет. Писал я под J2ME несколько лет назад для своей мобилы, помню эти рекомендации прекрасно.
J2ME — они разные бывают. В некоторых из них используется (до сих пор !) консервативный GC. Поэтому и такие рекомендации.

G>Никому не надо, говоришь? Думаешь, это так прикольно — все ссылки нулями затирать, да объекты переиспользовать? Все были бы рады нормальному GC на J2ME, который бы просто работал по человечески, да тока во встроенной системе с ограниченной памятью ты вообще никакого real-time гарантировать не сможешь. Там элементарно создать ситуацию, когда хип забит, после чего он разом освобождается, а твоя программа просит памяти еще. Вот stop and copy коллектор такой проблемы лишен by design, почему он и применяется в Эрланге.
Это нужен просто НОРМАЛЬНЫЙ GC, а не realtime.

C>>Хахаха. Трехцветный mark&sweep известен где-то с 70-х годов. Все основные изменения в нём уже сделаны, ускорить его сильнее — нельзя в принципе. Кроме того, у mark&sweep есть два фатальных недостатка: фрагментация кучи и зависимость времени работы от количества всех объектов (а не только живых как у stop-the-world).
G>Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад.
А я ей интересуюсь постоянно. GC — это моя область экспертизы, механизмы работы GC в Java я знаю буквально до ассемблерных команд.

G>Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема.
Да нифига это не проблема! Это решается простейшим трехцветным GC (tri-color GC, tri-color mark&sweep), корректность работы которого была доказана Дейкстрой (AFAIR) в качестве примера доказательства параллельных алгоритмов. Год точно не вспомню, но точно раньше 80-х, так как я лично держал в руках вариант Схемы начала 80-х годов с таким сборщиком.

Так что лучше и меня иногда послушай

G>Вот скажем, в информационном письме IBM от 2003 года они с гордостью писали, что в новом релизе IBM JVM им удалось довести гаранированную задержку на GC до такой малой величины, как половина секунды.
Вполне нормально для обычного не-realtime.

G>Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста.
Azul Systems это УЖЕ предлагает коммерчески. Их системы УЖЕ успешно используются для realtime-трейдинга. Чисто программные системы — Sun RTSJ ( http://java.sun.com/javase/technologies/realtime/ ), Aonix и еще штук 5 таких же.

Они не распространены из-за того, что за них денег просят.

C>>Могу прислать whitepaper от Azul Systems, если интересно подробнее.
G>Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо.
Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.