Почему команда в LMAX использовала Java и проектировала архитектуру, чтобы любой ценой избежать GC?

Почему команда в LMAX разработала LMAX Disruptor в Java, но все их разработки сводятся к минимизации использования GC? Если кто-то не хочет запускать GC, зачем использовать язык сборки мусора?

Их оптимизация, уровень знаний об оборудовании и мысли, которые они вкладывают, просто потрясающие, но почему Java?

Я не против Java или чего-либо, но почему язык GC? Почему бы не использовать что-то вроде D или любой другой язык без GC, но позволяет эффективный код? Это то, что команда больше всего знакома с Java или у Java есть какое-то уникальное преимущество, которого я не вижу?

Скажем, они разрабатывают его, используя D с ручным управлением памятью, какая разница? Они должны думать о низком уровне (которым они уже являются), но они могут выжать лучшую производительность из системы, поскольку она является родной.

Потому что есть огромная разница между оптимизацией производительности и полным отключением безопасности

Благодаря уменьшению количества сборщиков мусора их структура становится более отзывчивой и может работать (предположительно) быстрее. Теперь оптимизация для сборщика мусора не означает, что они никогда не собирают мусор. Это просто означает, что они делают это реже, и когда они делают это, они работают очень быстро. Эти виды оптимизации включают в себя:

1. Минимизация количества объектов, которые перемещаются в пространство для выживших (то есть, которые пережили хотя бы одну сборку мусора) с помощью небольших одноразовых объектов. Объект, который переместился в пространство выживших, сложнее собрать, и сборка мусора здесь иногда приводит к зависанию всей JVM.
2. Не выделяйте слишком много объектов для начала. Это может иметь неприятные последствия, если вы не будете осторожны, поскольку объекты молодого поколения очень дешевы в размещении и сборе.
3. Убедитесь, что новый объект указывает на старый (а не наоборот), чтобы молодой объект можно было легко собрать, поскольку нет ссылок на них, которые могли бы его сохранить

Когда вы настраиваете производительность, вы обычно настраиваете очень специфическую «горячую точку», игнорируя код, который не часто запускается. Если вы сделаете это в Java, вы можете позволить сборщику мусора по-прежнему заботиться об этом темном углу (так как он не будет иметь большого значения), в то же время очень тщательно оптимизируя область, которая работает в узком цикле. Таким образом, вы можете выбрать, где вы оптимизируете, а где нет, и таким образом вы можете сосредоточить свои усилия там, где это важно.

Теперь, если вы полностью отключите сборку мусора, вы не сможете выбрать. Вы должны вручную избавиться от каждого объекта, когда-либо. Этот метод вызывается не чаще одного раза в день? В Java вы можете позволить этому быть, так как его влияние на производительность незначительно (может быть, допустимо, чтобы полный GC происходил каждый месяц). В C ++ у вас все еще утечка ресурсов, поэтому вы должны позаботиться даже об этом неясном методе Таким образом, вы должны заплатить цену за управление ресурсами в каждой отдельной части вашего приложения, в то время как в Java вы можете сосредоточиться.

Но это еще хуже.

Что если у вас есть ошибка, скажем, в темном углу вашего приложения, доступ к которой возможен только в понедельник в полнолуние? У Java есть сильная гарантия безопасности. Существует практически нет "неопределенного поведения". Если вы используете что-то неправильно, выдается исключение, ваша программа останавливается, и повреждение данных не происходит. Таким образом, вы уверены, что ничего плохого не произойдет, если вы не заметите.

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

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

Отключение безопасности стоит. Быть родным не всегда имеет смысл. Иногда гораздо проще и безопаснее просто немного оптимизировать безопасный язык, чтобы пойти ва-банк с языком, на котором вы можете застрелиться в ногу. Правильность и безопасность во многих случаях превосходят несколько наносекунд, которые вы могли бы списать, полностью исключив ГХ. Disruptor может быть использован в тех ситуациях, так что я думаю , что LMAX-биржа сделала правильный вызов.

Но как насчет D в частности? У вас есть GC, если вы хотите для темных углов, а подмножество SafeD (о котором я не знал до редактирования) удаляет неопределенное поведение (если вы не забываете его использовать!).

Ну, в таком случае это простой вопрос зрелости. Экосистема Java полна хорошо написанного инструмента и зрелых библиотек (лучше для разработки). Гораздо больше разработчиков знают Java, чем D (лучше для обслуживания). Переход на новый и не очень популярный язык для чего-то столь важного, как финансовое приложение, не был бы хорошей идеей. С менее известным языком, если у вас есть проблема, мало кто может вам помочь, и библиотеки, которые вы обнаружите, имеют тенденцию иметь больше ошибок, так как они были выставлены меньшему количеству людей.

Поэтому мое последнее замечание остается в силе: если вы хотите избежать проблем с тяжелыми последствиями, придерживайтесь безопасного выбора. На данный момент в жизни D его клиенты - маленькие стартапы, готовые пойти на сумасшедший риск. Если проблема может стоить миллионы, вам лучше оставаться в курсе инновационной кривой .

Кажется, причина того, что он написан на Java, заключается в том, что у них есть собственный опыт работы с Java, и он, вероятно, был написан (хотя он все еще находится в активной разработке) до того, как C ++ начал действовать вместе с C ++ 0x / 11.

Их код на самом деле является только Java по названию, они используют sun.misc.Unsafe, что немного противоречит точке зрения Java, и безопасность якобы дает. Я написал порт C ++ для Disruptor, и он превосходит Java-код, который они поставляют (я не тратил много времени на настройку JVM).

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

Этот вопрос утверждает неверную предпосылку как факт, а затем приводит аргумент об этой неверной предпосылке.

Давайте разберемся с этим ... "все их точки дизайна сводят к минимуму использование GC" - просто не соответствует действительности. Инновация в разрушителе имеет мало общего с GC. Разрушитель работает, потому что его дизайн ловко учитывает, как работают современные компьютеры - что встречается гораздо реже, чем можно было бы ожидать. См. Выступление Клифф Клик http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdf для обсуждения.

Общеизвестно, что LMax являются клиентами Azul. Я знаю из первых рук, что с Azul GC просто нет, даже с кучей в 175 ГБ.

Они должны думать о низком уровне

Выше составляет половину ответа, который вы ищете. Вы можете найти другую половину, чтобы завершить рассуждение не дальше, чем в блоге LMAX :

Хотя он очень эффективен, он может привести к ряду ошибок, поскольку его очень легко испортить ...

По признанию разработчиков LMAX, подобный код может быть довольно сложным для разработки, понимания и отладки - даже на Java. Переход на более низкий уровень дальше, чем там, где они сейчас, только усугубит эту проблему, как указано в статье Википедии о языках программирования низкого уровня :

Программа, написанная на низкоуровневом языке, может быть запущена очень быстро и с очень маленьким объемом памяти; эквивалентная программа на языке высокого уровня будет более тяжелой. Языки низкого уровня просты, но считаются сложными в использовании из-за многочисленных технических деталей, которые необходимо запомнить .

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

Если вы используете Java в качестве языка синтаксиса и избегаете его библиотек JDK, он может быть таким же быстрым, как и скомпилированный язык без GC. GC не подходит для систем реального времени, но можно разрабатывать системы на Java, которые не оставляют мусора. В результате GC никогда не срабатывает.

Мы считаем, что язык и платформа Java имеют много преимуществ по сравнению с C / C ++, и мы разработали и протестировали некоторые компоненты Java со сверхнизкой задержкой, чтобы доказать это. Мы поговорим о методах, используемых для этого в этой статье: Разработка Java без GC .

LMAX - это высокопроизводительная библиотека обмена сообщениями между потоками.

Чтобы быть полезным, кто-то другой должен написать код, чтобы каждый поток выполнял полезную работу. Учитывая, что код, скорее всего, написан на Java или C #, и тогда очень мало вариантов выбора языка, которые хорошо с ними взаимодействуют.

Использование C или C ++ не является хорошим вариантом, если вы не хотите ограничивать пользователей одной ОС, поскольку в них не определена модель потоков.

В наши дни Java является стандартом для многих программных разработок, поэтому, если у вас нет веских причин, это лучший выбор. (Когда в Риме делают, как римляне ...)

Написание высокопроизводительного программного обеспечения на Java (или C #) часто делается, чтобы доказать свою точку зрения…