> Бенчмарки эти можно выпускать в рулонах. Тупую числодроилку любой JIT способен заоптимизировать
> по самое не могу, но даже не смотря на это Java
> сливает сям в несколько раз.

От небольшого выигрыша до проигрыша 4x в зависимости от задачи:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

И при этом остается самой быстрой среди VM.

>Другое дело - реальный мир, где
> всё течёт, интерфейс кошмарно тормозит, а через сутки работы начинает просто
> дёргаться после каждого события, память утекает гигабайтами, а если её ограничить,
> приложение начинает залипать в GC на целые секунды.

Почему вы уверены, что это проблема Java вообще, а не конкретного приложения?

> Поставил, сделал пару
> звонков, RSS стало 1723. Совершенно не удивился и со спокойно снёс.

Ограничение на размер кучи в JVM по умолчанию зависит от количества доступной оперативной памяти. Памяти много — мусор можно чистить реже. Посмотрел в Jitsi: в версии, которую я скачал (установщик jitsi-1.0-latest.jar), в скрипте запуска включается ограничение -Xmx256m, но почему-то только для 32-битных систем.

Я бы не сказал, что мне этот Jitsi понравился, но этот проблема самого Jitsi, а не Java.