25 марта 2016 г.

А почему бы не аллоцировать на стеке?

В самом деле: почему? Вот мы прогнали escape analysis на коде метода, обнаружили, что такие-то создаваемые объекты за пределы метода не утекают. Зачем мы их скаляризуем, почему бы нам просто не аллоцировать их на стеке? Ведь скаляризация, на первый взгляд, сложнее аллокации на стеке: отследить, какие операции с полями объектов к именно какому объекту в этот момент относятся, завести под эти поля локальные переменные, преобразовать код, чтобы он обращался к этим переменным, а не к полям объекта, приготовить задел для деоптимизации... Зачем нам весь этот геморрой, когда можно просто выделить кусок памяти на стеке, и впечатать туда объект? И мы получим полноценную ссылку на него, ничем не отличающуюся от ссылки на объект в куче. Ссылку, которую можно запихнуть в любую дырку, куда пролезет обычная ссылка (ну, слишком-то глубоко мы ее не запихаем — мы же знаем, что за пределы метода она не уйдет).

Насколько я понимаю, одного простого ответа на это "почему" нет. Более того, существовали прототипы стековой аллокации — в одной из статей по EA авторы упоминают, что их прототип делал по результатам EA именно стековую аллокацию (правда, тот прототип был на базе IBM JVM).

Но стековая аллокация не так уж проста, когда речь заходит о деталях: JVM (Oracle/Open JDK) знает, сколько памяти выделено ей под кучу — эта информация задается при запуске, и не может быть изменена. И VM этим пользуется: сразу же при старте резервирует у ОС диапазон адресов размером с максимальную кучу (не аллоцирует память, а просто резервирует адреса HEAP_START..HEAP_END = -Xmx реальная же аллокация происходит по необходимости). И с самого первого момента жизни у JVM есть эти два числа [HEAP_START..HEAP_END], между которыми должно лежать значение любого указателя на java-объект, и JVM активно полагается на то, что куча это непрерывный кусок памяти [HEAP_START..HEAP_END]. Например, эти числа можно вклеивать в генерируемый код прямо в виде констант.

Или, например, card marking. Я уже как-то писал о нем в контексте concurrency: generational GC должен как-то отслеживать ссылки между объектами разных поколений. Чтобы собрать молодое поколение, нужно знать, какие ссылки на него существуют в полях объектов старого поколения (они становятся частью root set-а). Разумеется, сканировать старое поколение целиком значит похоронить всю идею generational GC, объем сканирования нужно как-то сузить. Для этого JVM разбивает кучу на блоки-"карты" размером 512 байт, и для каждого такого блока держит однобайтовый признак "была ли в пределах этого блока запись ссылки". Каждая запись ссылки обновляет заодно и card marks: очень грубо, строчка a.f = ref из java-кода превращается примерно в
a.f = ref;
cardMarks[ (addressOf(a.f)-HEAP_START) >> 9 ] = 1
Т.е. мы записали ссылку в поле какого-то объекта, и пометили блок памяти, содержащий этот объект, как модифицированный. (Это относится только к записям ссылок — примитивные типы card marks не обновляют, потому что GC до них нет дела). Перед сборкой молодого поколения GC пройдет все модифицированные блоки, соберет из них ссылки, ведущие в молодое поколение, и добавит их в root set.

Код card marking такой простой потому, что мы заранее знаем начало кучи, какого она размера, и что она непрерывна. Поэтому нам достаточно одного-единственного массива cardMarks, и мы можем уже на старте JVM аллоцировать его нужного размера (= HEAP_SIZE / 512), сразу подо всю, даже еще не аллоцированную, кучу. Очевидно, что если теперь a в коде выше вдруг указывает на объект на стеке, то мы получим выход за границы массива cardMarks, потому что стеки потоков точно никак не попадут в зарезервированный под кучу интервал адресов. Чтобы обрабатывать ссылки на объекты в куче и объекты на стеке одновременно нужно, чтобы код card marking-а был заметно сложнее, скорее всего, содержал какие-то проверки и условные переходы. А это, на минуточку, код записи ссылки — одна из самых базовых операций, из самых часто исполняемых фрагментов кода. Типичная java-программа ссылками оперирует, пожалуй, чаще, чем примитивными типами! Получается, что немного ускорив аллокацию (точнее, де-аллокацию, сборку мусора — аллокация из TLAB в яве и так быстрее некуда) за счет использования стека мы одновременно замедлили один из самых горячих фрагментов кода — запись ссылки. Какой итоговый эффект это окажет на производительность/время отклика приложения в целом — большой и нетривиальный вопрос.

Card marking это только один из примеров того, как неожиданно непросто впихнуть стековые объекты в архитектуру JVM, годами заточенную под манипуляции объектами из кучи. Этот пример простой, но, возможно, уже не самый актуальный — как я понимаю (могу ошибаться), в G1 уже пришлось делить общий массив cardMarks на отдельные массивчики для каждого блока. Возможно, теперь уже не так уж сложно втиснуть в эту схему еще несколько "блоков" для стеков потоков. Но это не единственный такой пример, если судить по переписке в hotspot-dev:

...I tried implementing direct stack allocation in Hotspot a couple of years ago. It was a pain to try to allocate anything outside the heap - there are a lot of checks to make sure that your objects live on the heap. I ended up creating TLAB-like regions in the heap that could hold objects allocated in a stack-like way. It was a lot easier that way, and seemed to give the kinds of performance benefits you would expect. (Jeremy Manson, 01/27/14, @hotspot-dev)

— оказывается, что проще создать свой собственный "стек" с гетерами и панкратионом: откусывать от общей кучи пулы памяти на каждый поток, и использовать их для аллокации неубегающих объектов, на манер стека. И прототип реализации был написан еще два года назад. И где тот стек сейчас?..

...Я сейчас думаю, что, возможно, дело вообще не в сложности технической реализации аллокации на стеке. Дело в том, что непонятно, так ли уж это нужно. В самом деле, чтобы устранить аллокацию в куче нужно а) чтобы алгоритм EA сумел показать, что объект не утекает за границы текущей единицы компиляции б) чтобы алгоритм скаляризации сумел преобразовать все обращения к этому объекту в обращения к его скаляризованной версии. Переход от скаляризации к аллокации на стеке улучшит пункт "б" (сделает его почти 100%-ным). Сейчас, в некоторых случаях, алгоритм скаляризации может спасовать, даже если алгоритм EA и распознал локальность объекта, а с введением аллокации на стеке почти все такие случаи будут обрабатываться. Но вот много ли таких случаев? Точнее: во-первых, в каком проценте случаев скаляризация пасует сейчас, и во-вторых — какой процент от общего числа аллоцированных в программе объектов мы сможем таким образом выиграть? Я экспериментирую сейчас с различными сценариями, и складывается ощущение, что ответ на первый вопрос может быть довольно заметным — ну, скажем, сейчас мы скаляризуем 60-70% объектов, распознанных EA как неубегающие, а будем аллоцировать на стеке все 100%. А вот общий эффект для среднестатистической программы может быть скромным, если вообще заметным.

Вот недавно мне попалась (спасибо твиттеру) свежая статья, про очередной улучшенный алгоритм EA, в конце каковой статьи приведены результаты применения улучшенного алгоритма к разным бенчмаркам из наборов DeCapo и SPECjbb2005. Результат: в среднем устранено примерно ~15% аллокаций в куче. Это довольно продвинутый алгоритм EA, в паре со "стековой" аллокацией — то есть, приблизительно и ориентировочно, можно взять эти 15% аллокаций за оценку сверху возможностей используемого сейчас алгоритма EA. И переход от используемой сейчас скаляризации к какому-нибудь варианту "стековой" аллокации позволит выиграть какую-нибудь треть от этих 15%.

Каким бы совершенным не был "скаляризатор", его поле деятельности ограничено теми не-убегающими аллокациями, которые ему скормит EA. Алгоритм EA в java почти не менялся со времен 1.6. Да и чисто теоретически: возможности EA отыскать не-убегающие аллокации, в свою очередь, тоже ограничены: в пределах одного метода, даже с учетом агрессивного инлайнинга, особо не развернешься, а межпроцедурную оптимизацию JIT сейчас не выполняет. Увеличивать агрессивность инлайнинга? — Неплохой вариант, в основном потому, что дает пинок, наряду со скаляризацией, сразу целому ряду других оптимизаций. И действительно, в 1.8 многие ограничения на инлайнинг ослаблены, и я вижу, как некоторые сценарии, не скаляризовавшиеся в 1.7, в 1.8 начали скаляризоваться. Но особо далеко по этому пути тоже не пройдешь: чрезмерный инлайнинг раздувает код, и с какого-то момента это начинает уже ухудшать производительность. Получается, что существенный прирост можно получить только совершенствуя сразу и скаляризацию, и алгоритм EA, и, по-возможности, увеличивая размер единицы оптимизации, либо подключая межпроцедурную оптимизацию.

В таком рассуждении есть нюанс: когда мы пытаемся оценить профит от улучшений, прогоняя их на существующих уже программах, мы незаметно попадаем в ловушку. Существующие программы написаны с использованием существующих практик написания кода, и в этих практиках — и вообще в опыте разработчиков — уже учтены характерные особенности языка и платформы. Опытные разработчики, сознательно или бессознательно, уже оптимизируют свой код под известные сильные и слабые стороны платформы. Говоря проще: если бы было общеизвестно, что в java есть великолепный EA и скаляризатор, и что редкий временный объект имеет шанс быть аллоцированным в куче — многие программы были бы написаны сильно иначе, чем они написаны сейчас, когда общеизвестно, что да, GC довольно неплохо управляется с короткоживущими объектами, а некоторые объекты даже и скаляризуются, но не всегда, и не все, и вообще как фишка ляжет. В упомянутой выше статье, наряду с набором java-бенчмарков, был взят аналогичный набор Scala-бенчмарков (ScalaDeCapo). И разница очень заметна: (Java)DeCapo от включения EA получает бонус в -5% аллокаций, а ScalaDeCapo — в -15%. Общий прирост производительности (Java)DeCapo: +2.2%, ScalaDeCapo: +9%. В Scala другие наборы best practices, другой компилятор, другая стандартная библиотека...

53 комментария:

  1. >a.f = ref;
    >cardMarks[ (ref-HEAP_START) >> 9 ] = 1
    Тут, наверное, должно быть
    cardMarks[ (a-HEAP_START) >> 9 ] = 1

    >Очевидно, что если теперь ref в коде выше вдруг указывает на объект на стеке, то мы получим выход за границы массива cardMarks
    Но ведь в такой ситуации объект просто нельзя скаляризовать, потому что ссылка на него утекает?

    >Дело в том, что непонятно, так ли уж это нужно
    Кажется, что project Valhalla покроет все случаи, в которых аллокация на стеке могла бы дать какой-то выигрыш, поэтому непонятно, зачем вообще продолжать улучшать EA, когда можно довести до законченного состояния гораздо более "вкусную" фичу

    ОтветитьУдалить
    Ответы
    1. >Тут, наверное, должно быть cardMarks[ (a-HEAP_START) >> 9 ] = 1

      Да, спасибо, я поправил. Заодно и в тексте дальше не ref, а "а" указывает на объект на стеке. То есть мы записываем ссылку на что угодно в поле объекта, аллоцированного на стеке. Никакого утекания для объекта на стеке здесь не возникает

      >Кажется, что project Valhalla покроет все случаи, в которых аллокация на стеке могла бы дать какой-то выигрыш, поэтому непонятно, зачем вообще продолжать улучшать EA, когда можно довести до законченного состояния гораздо более "вкусную" фичу

      Как и во многих аналогичных случаях, принципиально новая фича языка даст возможность писать более лучший код -- но не улучшит уже написанный код. Кроме того "более лучший" код заодно станет и более сложным для написания и понимания. Сколько человеко-лет потребуется, чтобы оптимизировать с помощью value objects все узкие места в уже написанных приложениях? А чуть более совершенный EA/SA сделает это сразу и для всех (установивших очередное обновление), и без изменений кода программ.

      ValueObjects позволяют делать некоторые вещи, которые без них делать почти невозможно -- например, компактная компоновка массивов value objects. Насколько я могу судить, до такой штуки компилятору догадаться сложно. В то же время обычные переменные типа Complex/Vector2D вполне можно скаляризовать и автоматически, без явного указания программиста. И код останется простым и _привычным_ -- как деды писали :)

      В общем, гипотетически, я за то, чтобы довести скаляризацию до ума, а потом уже делать value objects как возможность для оптимизации немногих оставшихся действительно узких мест. Увы, похоже, что время несколько упущено: со времен 1.6 EA существенно не улучшился, а необходимость в скаляризации ссылочных объектов все нарастает. Да и возможно ли было существенно улучшить EA -- тоже не очевидно.

      Удалить
    2. Да, никакого утекания не будет, спасибо.

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

      Судя по статье, основной выигрыш их алгоритма в частичном анализе — возможности двигать аллокации (и не только аллокации, а еще и lock elision) внутрь условных переходов, избавляясь от них в соседних ветках. Сразу же возникает вопрос — а много ли существует таких кейсов, где такая оптимизация действительно дает значительный выигрыш (есть "условная" аллокация на hot-path'е приложения)? Числа из бенчмарков выглядят внушительно, однако там мелким шрифтом написано, что "We evaluated our implementation of Partial Escape Analysis, which is built on top of the Graal compiler, by running and analyzing a number of benchmarks. The original Graal compiler does not perform any kind of Escape Analysis." :)

      Там чуть дальше маленький абзац про сравнение с hotspot'ом. Соотношения hotspot/graal на De Capo и SPECjbb это 0.9/2.2 (7.4/10.4 для скалы) и 5.4/8.7 % в среднем. Здесь уже треть аллокаций для типичного приложения (игнорируя скалу с ее стектрейсами) это доли процента. Получается совсем незначительный выигрыш ценой усложнения кодовой базы (на конференциях все любят рассказывать, какой в компиляторе адъ и как тяжело вносить туда изменения), которая и без того непростая (+человеко-часы на разработку и поддержку этого). Кажется, что тем, кому действительно важен этот процент аллокаций в состоянии заплатить квалифицированным инженерам, чтоб они воткнули соответствующий костыль :)

      А вот польза value-типов бесспорна (я надеюсь): новый код можно сделать на специфичных кейсах _гораздо_ быстрее и радоваться жизни, когда как чуть более совершенный EA даст какие-то копейки уже существующим приложениям, которые еще и не факт, что им нужны.

      Удалить
    3. >но здесь мой поинт похож на твой про терабайтные хипы: скольким % пользователей такой выигрыш действительно нужен и насколько большой прирост это даст среднестатистическому приложению?

      Да, я ж поэтому и пишу: не факт, что можно (существенно) улучшить.

      В целом, у меня по экспериментам действительно складывается ощущение, что
      1. Кардинально EA не улучшить.
      2. ...потому что он уже довольно неплох -- накрывает приличный процент случаев, теоретически накрываемых с учетом принципиальных ограничений оптимизатора (только внутрипроцедурный анализ, ограниченная глубина инлайнинга...)
      3. ...а большинство проблем возникает именно на стадии скаляризации

      Основная проблема с оптимизацией EA/SA которую я, как разработчик вижу -- это что про нее мало информации. Например, про девиртуализацию и инлайнинг довольно много описаний -- как это работает, какие ограничения, в каких случаях и сколько будет стоить примерно. Шипилёв про это немало говорил и писал. И эта информация позволяет примерно прикидывать, в том числе еще на стадии проектирования кода, с какими архитектурными изысками JIT способен будет разобраться (возможно, с некоторой помощью), а с какими принципиально нет.

      А вот про EA/SA такой информации я пока нигде не видел. И, по-моему, это хреново. Потому что, с моей точки зрения, вовсе нет необходимости, чтобы JIT был способен скаляризовать все на свете, и не оставлял работы для GC (это и невозможно). Мне вполне нормально жить с 10-15% скаляризуемых аллокаций -- но это должны быть _предсказуемые_ аллокации.

      Вот у меня есть горячий код, и мне нужно вернуть из метода кортеж. Я хочу знать, могу ли я так и написать return Pair[A,B], и рассчитывать на то, что JIT его скаляризует? Или надежды нет, и надо заранее думать, как обойтись без этого?

      Если EA/SA будет для меня предсказуемым -- я смогу писать высокопроизводительный, маломусорящий код, который тем не менее не будет похож на С, будет нормально выглядеть и читаться.

      Вот "Partial Escape Analysis..." мне интересен с двух сторон: во-первых, просто интересный подход, не похожий на другие алгоритмы. В альтернативных алгоритмах пытаются приближенно статически "выполнить" код, построив приближенный же граф ссылок, а здесь код трансформируют, пытаясь прийти к состоянию, где аллокации уже просто нет. А во-вторых этот алгоритм как раз накрывает один из частых паттернов (спекулятивно создали-проверили нет ли уже-выкинули или сохранили) где хотелось бы получить скаляризацию.

      Удалить
  2. При работе с огромным количество объектов когда писать их в хип - все равно что вбить гвоздь в гроб jvm, объекты сериализуется и пишутся в преаллоцированные сегменты хипа или офхипа.

    При таком подходе GC чувствует себя ну очень хорошо безо во сякой аллокации на стеке кстати.

    Достаточно просто немного подумать и спросить - а мне действительно нужен этот "new Bla Bla".

    В огромном количестве случаем можно уйти от созданий нового объекта как такового. Так что в некотором смысле проблема стековой аллокации обходится написанием вменяемого кода.

    ОтветитьУдалить
    Ответы
    1. В огромном количестве случаев создавать объект не обязательно. Но очень удобно. Очень. Одна только иммутабельность чего стоит.

      Безусловно, можно обойтись без умного компилятора, обойтись умным разработчиком. Но мне кажется, что перекладывать работу компилятора на человека -- это не разумное решение, в перспективе. За свою карьеру я встречался с ошибками компилятора несколько десятков раз. За это время я сам ошибался несколько тысяч раз. Компилятору, как правило, я доверяю больше, чем себе )

      То же самое и с аллокацией за пределами кучи, со всеми этими самописными аллокаторами -- мы берем ту работу, с которой компьютер пока не справляется, и делаем ее сами. Конечно, сейчас, может быть, просто нет выбора -- но в перспективе я бы предпочел, чтобы компьютер все-таки научился с ней справляться.

      Удалить
    2. Руслан тут проблема не компьютера
      Проблему я тебе уже описывал как проблему JVM.

      Ты тогда сказал дескать это нафиг не нужно для большинства задач и как только будет нужно - вот тут то Оракл нам создаст супер солюшен )))


      То есть спасением будет на аллокация на стеке - а реализация описанных мной
      подходов внутри библиотек JVM :)

      А аллокация на стеке - это вопли утопающего - чтобы дождь пошел - а то жарко )))

      Нам не дождь нужен - нам корабль нужен - чтобы не утонуть в том насколько безграмотно написана Java (Это мое ИМХО - понимаю что ты с этим не согласен :))

      Удалить
    3. создание объекта это не более, чем абстракция - так удобней мыслить (скрытие всей подноготной и все деталей), но вполне согласен, что не самый эффективный с точки зрения ресурсов подход.

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

      после прочтения
      https://blog.bramp.net/post/2015/09/09/unrolling-loops-at-runtime-with-byte-buddy/
      я всё присматриваюсь к нашему коду - мы размещаем, конечно, не так много как вы - всего лишь чуть меньше сотни Гб в оффхипе - и собственно, что если делать подмену байткода на лету - такой ad-hoc EA on demand - где оффхип, а где по старинке онхип - причем с точки зрения программиста всё останется так же new BlaBla - т.е та же абстракция - и овцы сыты, и волки целы

      Удалить
    4. >> что бОльшую часть времени процессор будет простаивать из-за ожидания загрузки той или совершенно иной области памяти

      Вот тут совершенно не понял - что имеется ввиду

      Удалить
    5. Думаю, Володя имеет в виду, что стек (или его альтернатива для короткоживущих объектов) всегда горячий в кэше. Чего не скажешь про сотни гигабайт оффхип памяти, где какой-то кастомный аллокатор выделяет место для твоего сериализованного объекта.

      Удалить
    6. >Ты тогда сказал дескать это нафиг не нужно для большинства задач и как только будет нужно - вот тут то Оракл нам создаст супер солюшен )))

      Не супер-солюшн, а просто подходящее решение. Или его создаст оракл, или без него создадут где-то в опенсорсе. Ровно то же самое было с G1: хипы начали расти, CMS перестал справляться, начали пилить новый алгоритм, допилили внедрили, часть проблем решилась, что не решилось -- решили люди типа Пангина для своих частных случаев. Никто не будет на халяву решать проблему терабайтных хипов, когда с этой проблемой сталкиваются 0.1% пользователей, которые вполне способны платить квалифицированным инженерам, способным решить эту проблему в частном случае именно для этих клиентов.

      Удалить
    7. @Vladimir:
      >что если делать подмену байткода на лету - такой ad-hoc EA on demand - где оффхип, а где по старинке онхип - причем с точки зрения программиста всё останется так же new BlaBla - т.е та же абстракция - и овцы сыты, и волки целы

      Мне кажется, что все эти идеи "сделать кастомный аллокатор/кэш объектов" недооценивают ту работу, что уже сделали разработчики JVM. Я имею в виду, что сделать лучше не так-то просто, особенно если речь идет про универсальное решение. В частном случае, для конкретного приложения, для конкретного сценария аллокации/деаллокации -- можно, но ценность непереносимого решения не так уж велика, а цена не так уж мала.

      Простой пример: пару месяцев назад я бенчмарчил свои кэши (на базе http://dev.cheremin.info/2012/06/simple-concurrent-caches.html, ты должен помнить). Вроде код вылизан как яйца у кота, однако найти готовый объект в линейном хэше все же в полтора-два раза дольше, чем создать новый объект. Конечно, здесь не учитывается стоимость GC, но пример все равно показателен: выигрывая в чем-то одном чаще всего проигрываешь в чем-то другом. No free lanch :)

      Удалить
    8. по поводу ожидания памяти - коллега мерял при помощи intel vtune и процессор простаивал очень много циклов ожидая подгрузки той или иной части памяти из оффхипа.

      что касается кастомного аллокатора - это скорее ускоспециализированное решение для узкого класса объектов и данных - как раз таки учитывая, сколько и как было сделано в jvm - некоторые индексы к значениям лежат в хипе, а сами данные в оффхипе - с переходом на 9ке более, чем уверен, мы пересмотрим в сторону value type'ов - ибо иметь этот геморрой дальше - утомительно

      Удалить
  3. плохой или хороший jvm (или openjdk) - это уже как предыстория к holly war - не ошибается лишь тот, кто ничего не делает, и у порядочного перфекциониста так ни одно дело и не начнется делаться (в силу того, что у всех в начале все идет криво).

    полно же других языков - и go, и erlang, и rust, и scala, и классический C (не С++ - хотя и он тоже), и упаси господи - node.js - опять же - не нравится, предложи своё, сделай свой луна парк с блекджеком и шахматистками - будет он так крут, обязательно появятся последователи

    ОтветитьУдалить
  4. Ну когда я пришел на проект и там Java - то ничего другого я предложить и выбрать на могу - должен писать на Java. Мог бы - выбрал бы язык D или тот же
    С++.

    ОтветитьУдалить
    Ответы
    1. Буквально, ты говоришь: "нам ужасно, ужасно плохо с GC, мы мучаемся с ним страшно, пишем всякие костыли -- но, несмотря на это, мы все равно выбираем джаву". Насколько же охуенная эта джава, что даже такие недостатки ей прощают! :)

      "Почему инструмент, который мы выбрали для решения наших задач, _так плохо сделан_?". А почему ты адресуешь этот вопрос авторам инструмента? Почему ты не задаешь вопрос "зачем _мы выбрали_ для решения наших задач настолько неподходящий инструмент?" У Максима Дорофеева я встречал "правило минимизации мудаков": наиболее вероятная причина каких-то проблем -- та, где количество мудаков минимально. Зачем ругать далекий Оракл, когда гораздо проще сказать, что мои нынешние начальники/техлиды -- дебилы, и выбрали неправильную технологию, на которой мы все теперь сидим и мучаемся?

      P.S. Мне "за державу обидно".

      Удалить
  5. Этот комментарий был удален автором.

    ОтветитьУдалить
  6. Ну во первых я не совсем понимаю чего обижаться на сказанное мною.
    Я всегда критически отзываюсь обо всем на свете - а уж о сделанном мной в 10 - кратном размере.

    Я понимаю что за джавой стоит толпа народу и многие ей там чуть ли не молятся - я лично пишу на ней последние 7 лет.

    И что ? Я попрежнему считаю неудачным многое из JVM.
    Можете обижаться - но Вы ведь сами постоянно холиварите на всякие темки типа

    - Ох уж этот UNSAFE
    - Хотим аллокацию на стеке
    - Блин как там этот реордеринг устроен
    - Черт JIT там чего то намудрил и перфоманс упал

    Все эти темы - следствие гигантской недоработки в идеологии языка.

    Мудаки тут непричем. Мудаки как правило выбирают то что в тренде о чем орут везде.

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

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

      Несложно написать GC, работающий с терабайтными хипами -- вот только с гигабайтными хипами он будет работать в разы медленнее. Но пользователей гигабайтных хипов 99%, и с таким GC джава для них не будет интересной. А значит джава останется уделом небольшого числа узкоспециализированных проектов. А раз так -- в нее мало кто будет инвестировать, а значит некому будет доводить до ума JIT, и разрабатывать толковую concurrent lib, JMM, и так далее. В итоге -- будет еще один эрланг.

      В реальности же мы имеем лучший в мире JIT, один из лучших созданных GC, одну из лучших concurrent lib, и так далее. Не идеал, но одна из лучших доступных платформ сейчас. Какой вариант тебе больше нравится?

      Чтобы было яснее: я ничего не имею против критики. Я просто не понимаю смысла критики в формате "джава написана безграмотно, GC ужасен". Это не критика, а выплескивание эмоций. Как можно было бы написать джаву грамотнее? Чем при этом пришлось бы пожертвовать?

      >Все эти темы - следствие гигантской недоработки в идеологии языка.

      А в каких языках ты не видишь таких идеологических недоработок? Более конкретный вопрос: где GC лучше, чем в джаве?

      >Мудаки как правило выбирают то что в тренде о чем орут везде.

      Так ты разве не об этом пишешь: для вашего проекта выбрали джаву, хотя она там совсем не подходит? ;)

      Удалить
    2. Я хотел сказать всего лишь одну мысль

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

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

      Плюс возможность включать - отключать JIT.

      >>Так ты разве не об этом пишешь: для вашего проекта выбрали джаву, хотя она там совсем не подходит? ;)

      То чем занимаюсь я можно написать и на джаве - что я собственно и делаю.
      Просто приходится кодить ровно то - что я бы очень сильно ждал от самой джавы.

      Достаточно конструктивно и без эмоций.

      А когда я говорю что джава безграмотна - здесь нет эмоций - она и правда
      безграмотна.



      Удалить
    3. @Alexander
      экспериментальные ветки со своими GC, включением его или отключением уже далеко не редкость - в массовость оно вряд ли пойдет по некоторым соображениям. Для разнообразия еще посмотри на JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

      Unsafe и так планируют скрыть в 9ке и предлагают альтернативы - собственно авторы и не намеривались давать ему всем наружу - опять же - так вышло.

      Про безграмотность java это опять же - газификация луж - что было сразу бриллиантом ? javascript, который написали за 10 дней ?

      Удалить
    4. @Vladimir,

      >> в массовость оно вряд ли пойдет по некоторым соображениям

      Вот эти соображения меня и удручают.

      >>Unsafe и так планируют скрыть в 9ке и предлагают альтернативы - собственно авторы и не намеривались давать ему всем наружу - опять же - так вышло.

      А как быть с терабайтами библиотек, которые уже юзают UNSAFE ?

      >>Про безграмотность java это опять же - газификация луж - что было сразу бриллиантом ? javascript, который написали за 10 дней ?

      Никто не спорит - джава заметно прогрессирует от версии к версии

      Сделав то что я описал - она убьет С++ одним выстрелом и окончательно.

      Удалить
    5. @Alexander

      Кстати, кто мешает реализовать (и законтрибьютить в openjdk) политики GC для разных регионов и прочие ништячки ?

      Удалить
    6. Мешает отсутствие времени и сил

      И так кожу каждый день кучу кода глаза уже в кучу и времени ни на что вечно не хватает

      Хотелок целый тасктрекер и все кругом чего то хотят

      Удалить
  7. Этот комментарий был удален автором.

    ОтветитьУдалить
    Ответы
    1. У тебя в резюме что указано -- что ты опытный разработчик java, или опытный разработчик C? Поздравляю, ты внес свой вклад в социальный PR java. Весь социальный PR складывается вот из таких маленьких вещей.

      Кмк, те, кто хочет непыльную работенку - не сталкиваются с терабайтными хипами. А если сталкиваются, то просто увольняются. С этими задачами сталкиваются те, кто (осознанно или неосознанно) хочет погеморройнее, чтобы больше приложения для ума. И здесь все нормально, я сам так люблю. Единственное, что мне не очень понятно: если сам влез туда, где сложно, где нет готовых инструментов -- то зачем критиковать авторов инструментов? Всегда же есть работа сайтики клепать, и без особых проблем с GC...

      Удалить
    2. >> то зачем критиковать авторов инструментов

      Я не критикую авторов - я критикую инструмент.

      Описанная мной идея решила бы и твою проблема с аллокаций не стеке -
      когда ты просто говоришь - вот все объекты в этом методе аллоцируй в
      этом регионе - (в котором отключен гц например)

      - а по выходу из метода - ставь указатель в начало региона.

      Регионы могут быть тредлокальными - что решило бы и проблему конкурентного доступа к данным

      Удалить
    3. Мне кажется, это не "решение", а ограниченный workaround. Кто будет заниматься этим "аллоцируй здесь"/"де-аллоцируй сейчас"? Кто будет следить за тем, чтобы ты не упустил ссылку на локальный объект за пределы времени жизни локальной зоны памяти? Если программист -- то это возвращение мира С/С++, с регулярными access violation и еще более регулярной тихой и незаметной порчей данных. Если отсутствие в стандартной библиотеке такой замечательной возможности стрелять себе в ноги ты называешь "безграмотным" -- то мы, очевидно, разное понимаем под грамотностью. Джава -- язык с безопасным доступом к памяти, это одна из первых вещей, которые тебе при знакомстве с платформой объясняют.

      А за пределами стандартной библиотеки такая возможность есть -- Unsafe/будущий VarHandle. Для дерзких и внимательных, и похороны за ваш счет.

      Если же следить за этим ты предлагаешь JVM, то это и есть аллокация на стеке/в зонах (memory zones). Явная -- как ValueObjects, или неявная -- как автоматическая скаляризация.

      Удалить
    4. Хм то что ты называешь workaround это просто частный случай общей идеи.

      Безграмотным я называю то как сделана работа с памятью

      Выделили сплошной кусок - назвали его хип - и там трава не расти.

      Вот это я и называю беграмотным.

      Почему хип один ?
      Почему я не могу выделять еще хипы с своими политиками сборки мусора ?


      Как это делать и кто будет следить - вопрос десятый.

      Никакого ухода в С++ здесь не будет

      Каждый регион будет таким же хипом что и сейчас.

      >> Джава -- язык с безопасным доступом к памяти, это одна из первых вещей, которые тебе при знакомстве с платформой объясняют

      Безусловно - я не предлагаю от этого уходить ...

      Так мало того - из за отсутствия грамотной работы с памятью - программисты типа Паньгина вынужднеы брать UNSAFE и уходить
      в мир С++.

      Вот и вся грамотность джавы тут заканчивается в реальной жизни.

      Удалить
    5. http://wiki.dlang.org/Memory_Management

      Вот как это сделано в языке D

      Удалить
    6. >Вот как это сделано в языке D

      "Если бы у бабки был хуй -- она была бы дедом". А если бы у джавы был memory management как в D -- то джава была бы D.

      Ответ на вопрос "почему в джаве 20 лет назад не было сделано как в D через 20 лет" -- он же очевиден, достаточно просто перестать мыслить в терминах "разработчики джавы недоумки, которые не подумали чего будет не хватать через 20 лет в 0.1% проектов на джаве".

      Ответ на этот вопрос звучит так: потому что 20 лет назад _уже был_ популярный язык с явным управлением памятью. Он назывался C. И джава вовсе не собиралась становиться его заменой (слоган java is a new C появился уже в новом тысячелетии), она целилась быть _совсем другой_.

      Я задам тебе встречный вопрос, чтобы было понятнее: почему язык D появился сейчас, а не 20 лет назад? Что помешало?

      >Безграмотным я называю то как сделана работа с памятью
      >Выделили сплошной кусок - назвали его хип - и там трава не расти.
      >Вот это я и называю беграмотным.
      >Почему хип один ?

      Потому что сделать иначе, быстро удобно и безопасно -- для всех, а не только для нужд Александра и его текущего проекта -- стоит в разы дороже, чем то, как это было сделано.
      А потребность в этом появилась в последние лет 5-6 только, и то далеко не у всех.

      А теперь давай рассмотрим альтернативную историю: в 1990-х, когда 4Гб были редкостью даже для серверной машины, архитекторы джавы решили инвестировать усилия в фичи, которые начнут себя окупать через 20 лет. В ущерб вещам, реально потребным тогда -- UI, JIT, что там еще в 90х было нужно. Что было бы в итоге? В итоге вместо "джава это новый С" мы бы имели "джава это еще один фортран". Вот это было бы грамотно, да...

      Удалить
    7. >Почему я не могу выделять еще хипы с своими политиками сборки мусора ?

      Мне кажется, ты вряд ли себе представляешь, как непросто это реализовать (как отслеживать ссылки между хипами, например?), и как непросто могут между собой взаимодействовать такие хипы.

      Вот у тебя есть хип А, которым ты управляешь явно, и хип Б, который управляется автоматическим GC. При этом из хипа А у тебя ссылки ведут в хип Б. Что происходит с автоматическим GC в Б? Правильно, он начинает работать в холостую. А если объекты из Б, достижимые из А, в свою очередь ссылаются на объекты из хипа С?...

      Вот пример того, как это вызывает проблемы даже в обычных generational GC: http://psy-lob-saw.blogspot.de/2016/03/gc-nepotism-and-linked-queues.html Посмотри презентацию команды JVM твиттера, на которую Нитсан ссылается -- там чувак рассказывает, как они расследовали этот случай. Но сейчас это хоть случается нечасто. Ты предлагаешь досыпать сюда еще сложности -- а кто сможет с этой сложностью управиться? Не у каждого под боком есть twitter jvm team.

      Собрать из этого конструктора хипов рабочее приложение, чем-то существенно лучшее современных, смогут 1000 инженеров на всю планету. 100 инженеров в мире смогут расследовать случаи, когда в уже собранном приложении "что-то внезапно пошло не так". Остальные 100500 инженеров потратят лишнее время на изучение всей этой машинерии, и накрепко запомнят, что лучше стандартного одного хипа ничего нет. И ради тех 1000 что смогут с той сложностью управиться -- ты предлагаешь это делать?

      Оракл выбрал другой путь -- реализовал G1, который делает примерно это же, только в меньшем масштабе, и гораздо проще. Зато и применим почти каждым. По-моему, вполне грамотное решение.

      >Так мало того - из за отсутствия грамотной работы с памятью - программисты типа Паньгина вынужднеы брать UNSAFE и уходить
      >в мир С++.
      >Вот и вся грамотность джавы тут заканчивается в реальной жизни.

      С чего ты взял, что Пангин -- это "реальная жизнь"? По-моему, реальная жизнь джавы это вовсе не одноклассники, или твиттер c LMAX. По-моему, реальная жизнь джавы -- это 100500 веб-приложений на томкате, 100500 гуев, 100500 мелких серверных приложений. Которые нормально живут с грамотной дефолтной джавой, с CMS/G1. И еще какое-то количество не совсем стандартных приложений, которые сидят на Azul. А Одноклассники, и твиттер -- это особые случаи, которым никогда не хватает дефолтов. Ты вообще много знаешь проектов такого масштаба, которые обходятся стандартными инструментами? Все они активно работают напильником.

      А то, что глядя на монстров уже и мелкие игроки начинают думать "чем мы хуже, мы тоже на джаве да с Unsafe такое нахерачим" -- так это не проблемы джавы, это проблемы чьей-то гордыни.

      Удалить
    8. >>Потому что сделать иначе, быстро удобно и безопасно -- для всех, а не только для нужд Александра и его текущего проекта -- стоит в разы дороже, чем то, как это было сделано.

      Руслан ты некорректно воспринимаешь диалог.

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

      Я прекрасно понимаю как работать с большими объемами данных в
      текущей джаве.

      Я долго ресерчил эту тему и увидел как это делается
      Выделение регионов, менеджмент блоков итд итп

      Покодив подобное я стал смотреть на джаву как на какой то хак -
      частный случай - над тем как на самом деле должна управляться память.

      Вот оттуда и вылезло мое "неграмотная".

      А по поводу области применения джавы - это то о чем я тебе говорил

      хотим непыльную работенку (EJB там, Tomcat ...)
      ботаем устройство HashMap, ArrayList красиво улыбаемся на интервью,
      получаем свои 80К, обедаем с менеджером и жизнь удалась.




      Удалить
    9. >>Мне кажется, ты вряд ли себе представляешь, как непросто это реализовать (как отслеживать ссылки между хипами, например?), и как непросто могут между собой взаимодействовать такие хипы.

      >>как отслеживать ссылки между хипами, например

      А как сейчас это делают когда у нас YoundGeneration+ OldGeneration ?

      Справились ? Алгоритм у тебя описан в этой же статье.

      Не спорю - на двух хипах все будет куда сложнее -но не надо делать из
      этого сверхзадачу

      Удалить
    10. >Покодив подобное я стал смотреть на джаву как на какой то хак - частный случай - над тем как на самом деле должна управляться память.

      "Покодив UI на ассемблере я стал смотреть на текущий ассемблер как на некий хак -- частный случай над тем, как на самом деле должна быть организована работа с UI."

      Я повторю еще раз: я вижу это как неспособность видеть цельную картину. Ты сидишь на своей теме, тебе неудобно, и ты жалуешься на то, на что жаловаться безопасно -- на инструмент. Ты не хочешь замечать моего вопроса "с чего ты взял, что этот инструмент вообще _предназначен_ для этой задачи?" Ты не хочешь отвечать на вопрос "кто тебя _заставляет_ работать в проекте, где используются плохие инструменты?" Хорошо, что в вашем проекте не ядро ОС на джаве пишут -- ты бы, наверное, жаловался бы, что в джаве плохо с обработкой прерываний.

      Что я понимаю под цельной картиной? Кусочек этой картины, как ее вижу я -- это что джава стоит вовсе не на таких как ты, и даже не на таких, как линкедин и твиттер. Она стоит на тех самых 100500 простых разработчиках, пишущих простые и непритязательные приложения. И _для них_ все должно работать хорошо out of box -- а не для тебя, и не для твиттера. Потому что если для них не будет работать хорошо, то на рынке труда будет доступно очень мало этих самых разработчиков. А значит и профессионалов будет доступно меньше, потому что профессионалами не рождаются, в них вырастают. А значит и твиттер и линкедин _не будут использовать джаву_ -- откуда бы взяться тем разработчикам, которые там джаву будут использовать-то? И так далее: эта цепочка приводит либо к одному из самых популярных языков в мире, с огромным сообществом, обширной документацией, кучей библиотек и фреймворков, высокими зарплатами и стабильным спросом на разработчиков вот уже два десятилетия. Либо -- к чему-то вроде эрланга.

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

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

      Это я не к тому, чтобы тебя оскорбить. Это я к тому, что совершенно логично и весьма грамотно, что твои и схожие с твоими запросы -- стоят далеко не в топе приоритетов при развитии JVM.

      Удалить
    11. Этот комментарий был удален автором.

      Удалить
    12. Хорошо, предлагаю остановить этот холивар

      Я остался при своем мнении о безграмотности джавы - ты при своем
      окей пусть все так и будет дальше.

      P.S.:

      до Java я 3 года писал не Perl :) Вот уж где безграмотный язык- где разработчики даже не задумываются над тем как там управляется память и даже не знают как устроен внутри GC и есть ли он вообще )))

      Удалить
    13. >А как сейчас это делают когда у нас YoundGeneration+ OldGeneration ?

      Сейчас с этим справились инженеры оракла. Которые, на минуточку, все же чуть более квалифицированы, чем среднестатистический senior dev. И они потратили годы на то, чтобы согласовать между собой сборку мусора в разных частях кучи. У тебя есть десяток параметров, но в целом алгоритм спрятан внутри JVM. И все равно возникают тонкости.

      А ты предлагаешь "разобрать" эту кучу на части, и дать разработчикам возможность самим с этими частями чудить. Я и говорю, что чтобы из этого конструктора что-то осмысленное, работающее, и при этом нетривиальное (т.е. не один из современных вариантов) собрать, нужно иметь квалификацию как у разработчиков GC. Но если у тебя такая квалификация -- то форкай OpenJDK, и напиши сам подходящий тебе GC.

      Удалить
    14. Моя задача на текущем проекте написать подобное на Java.
      О чем ты вообще говоришь ?

      Зачем вы изобретаете всякие GF-логгеры ?

      Не устроил ГЦ ? А чего тогда вообще на джаве писали ?
      Почему не взяли C++ ?
      Почему не форканули OpenJDK и не отключили GC как это сделал LMax.

      Честно использовали преаллоцированные кольца, понимая, что иначе ГЦ
      убьет перфоманс закодили GF логгер

      Такая же фигня для остальный low-latency фич.

      Садитесь и кодите на джаве а не на С++ - как это следовало бы сделать по твоей логике.

      Ты должен бы уволиться из ДБ как только увидел low-latency приложение на
      джава назвав всех мудаками или побежать форкать OPENJDK и писать
      что то свое.

      Вот и я также как вы сажусь и средствами Java
      пишу алгоритмы работы над большими блоками данных.

      Удалить
    15. Вот именно, Саша: мы, встретившись с ограничениями инструмента, взяли и сделали то, чего нам не хватало. Как-то обойдясь без унизительных отзывов в адрес инструмента и безграмотности его разработчиков.

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

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

      Вот эта непоследовательность и неконструктивность меня и поражает.

      Удалить
    16. >> А ты либо крестик сними, либо партбилет сдай

      Ну вот это я и называл северокорейским подходом

      Я ничего никому не должен и считаю так как считаю.

      Когда я выбирал Java - я ничего про нее не знал и считал
      ее офигенным инструментом разработки.

      Осознание что джава безграмотна пришло совсем недавно - когда
      я погрузился в отличный от EJB/JSP спектр задач.

      И да для таких задач (а решать их хотят на джава - бизнес хочет)
      джава безграмотна.

      Ничего и никого я унижать не хотел.

      И подход - я пишу на Java - значит я ей восхищаюсь - тоже не работает.

      Я всегда стараюсь думать а не покланяться сообществам или языкам-
      сколько бы человек там не состояло.

      А ты мне предлагаешь покланяться и считать.

      Нет уже спасибо - избавь.




      Удалить
    17. >>Вот эта непоследовательность и неконструктивность меня и поражает.

      А меня поражает твоя непоследовательность и неконструктивность

      Если ты такой адепт Java - зачем тебе аллокация на стеке.

      Ну пусть GC шуршит в хипе - все же ок не так ли ?

      >>неконструктивность

      Ага называть мудаками людей просто потому что один из них назвал
      твое божество "Java" неграмотным - это верх конструктива.

      Удалить
    18. Да ну и так в довесок
      Твои любимые грамотные разработчики из Оракла совсем недавно приняли гениальное решение - а давайте вообще закроем UNSAFE.

      Ну нефига этим идиотам кодерам юзать такой офигенский инструмент -
      небезопасно.

      И так для справки - те кого ты называешь мудаками - сделали очень
      много чтобы Oracle не закрыл UNSAFE - и Паньгин говорил об этом в
      Питере.

      Это конечно гениальное решение закрыть либу - на которую релаится
      уже 100500 библиотечек разного пошива.

      Удалить
    19. >А ты мне предлагаешь покланяться и считать.

      Я тебе предлагаю забыть про черное-белое, и начать думать головой. Ты, как мне кажется, считаешь, что самостоятельность мышления -- это разрешать себе кого угодно называть безграмотным. Конечно, самостоятельность в этом есть. А вот есть ли мышление -- it depends. Самостоятельность мышления -- это способность задавать неудобные вопросы. Вот тебе неудобный вопрос, на который я так и не услышал ответа: как так вышло, что безграмотное решение используется одноклассниками, твиттером, линкедом, а так же твоим текущим проектом, и тобой лично? Как так вышло, что "а решать их хотят на джава - бизнес хочет"? При этом я так и не услышал от тебя, считаешь ли ты своих техлидов и свой бизнес безграмотными, почему тогда ты на них работаешь.

      >Осознание что джава безграмотна пришло совсем недавно - когда
      я погрузился в отличный от EJB/JSP спектр задач.

      Если ты пришел к этой идее совсем недавно -- я тем более не понимаю, с чего ты так в ней уверен. Любая идея должна пройти проверку временем, а ты уже сейчас так запираешься, как будто уж 10 лет живешь с этим знанием, и с ним прошел огонь и воду. Я вот давно уже живу в мире без EJB/JSP, и все еще считаю джаву весьма разумным компромиссом. Как так?

      >Ага называть мудаками людей просто потому что один из них назвал твое божество "Java" неграмотным - это верх конструктива.

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

      >Если ты такой адепт Java - зачем тебе аллокация на стеке.

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

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

      >Ну нефига этим идиотам кодерам юзать такой офигенский инструмент - небезопасно.

      Знаешь, Саша, я вот думаю, что людям, которые считают Unsafe "офигенским инструментом" -- и в самом деле не стоит его давать. Это действительно небезопасно. Вообще Unsafe можно бы и оставить, но использовать я бы доверил только людям, у которых Unsafe вне jdk вызывает рвотный рефлекс. Таким людям я доверяю -- они будут использовать Unsafe только там, где это правда необходимо. А если человек считает, что возможность делать все, что угодно это "офигенно" -- этому человеку рано еще давать возможность делать все, что угодно.

      Удалить
    20. >> Ты, как мне кажется, считаешь, что самостоятельность мышления --
      это разрешать себе кого угодно называть безграмотным

      Да нет - это не так.

      Я хочу сказать что в данный момент когда на джава стараются решать не
      только задачи EJB/JSP впору задуматься - а насколько джава грамотно
      написана для таких задачи.

      На Java их хотя решать по многим причинам:

      1) Отличная база из библиотек

      2) Огромная комьюнити и поддержка

      3) Много достаточно грамотных разработчиков

      И поэтому все упомянутые тобой компании используют Java.
      Java действительно крута в огромном количестве аспектов - но уволь
      работа с памятью там безграмотна.

      Есть чем возразить - возрази.

      Обоснуй почему ты считаешь что сегодня когда на Java пишут:

      - Low latency решения
      - Big data решения
      - NoSql хранилища
      - Терабайтные кеши

      Java и ее управление памятью является грамотным.

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

      Это по твоему грамотно сегодня ?

      Или что ты скажешь тем кому это нужно ?
      Вас 0.1% - не нравится - сдавайте парт билет - вас меньшинство.

      А эти люди хотят джобы Java стала грамотным инструментом и для этих
      задачи - назрело ее время - понимаешь.

      Ни аллокации на стеке, ни UNSAFE, ни что там еще -
      а грамотная работа с памятью.

      >> Знаешь, Саша, я вот думаю, что людям,
      которые считают Unsafe "офигенским инструментом"

      Не думаю что кто то так считает.

      Меня лично тошнит от UNSAFE и от любых попыток его юзать.
      Но в огромном числе задач - ну совсем никак нельзя жить - когда там GC.

      >> Моя позиция в том, что каждое решение в джаве -- это компромисс между множеством интересов

      Безусловно - и это я понимаю.
      Но также я понимаю что раз написали такое в D - то время (эпоха) задач
      требует от Java грамотной работы с памятью.

      Все устал. Пойду работать.

      Я все сказал.



      Удалить
    21. >Java действительно крута в огромном количестве аспектов - но уволь
      работа с памятью там безграмотна.
      >Есть чем возразить - возрази.

      Я тебе уже все объяснил: безграмотно оценивать работу с памятью "в изоляции". Работа с памятью -- это часть платформы джава, инфраструктуры джава, экосистемы джава, бизнес-модели джава. И как часть всех этих контекстов работа с памятью в джаве -- реализована грамотно. Невозможно поменять _только_ работу с памятью не затронув все эти контексты. Ты же упорно говоришь про какое-то управление памятью в сферическом вакууме.

      >А эти люди хотят джобы Java стала грамотным инструментом и для этих задачи - назрело ее время - понимаешь.

      Если бы эти люди действительно такого хотели бы -- они бы форкнули OpenJDK, и реализовали бы там такое управление памятью, как считают грамотным. Вот, Гил Тен хотел и сделал. А LMAX даже свою версию JVM с отключенным GC не выложил.

      >Но также я понимаю что раз написали такое в D - то время (эпоха) задач требует от Java грамотной работы с памятью.

      За D нет никакой истории. Про успешность стратегии D мы будем говорить через 20 лет. И я готов ставить бутылку шампанского, что если D доживет до того времени -- молодые разработчики ровно так же будут его хаять за безграмотность.

      >Обоснуй почему ты считаешь что сегодня когда на Java пишут:
      >Java и ее управление памятью является грамотным.

      Ок, я сделаю последнюю попытку, но тебе придется мне помочь. Открываешь пустой файл в блокноте, и пишешь:

      "
      Ларри Эллисону, от Александра Токтарева

      Бизнес-план -- обоснование

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

      .....
      "

      И дальше раскрываешь тему. Начни на русском, чтобы проще, на английский потом переведешь.

      Удалить
    22. >> Невозможно поменять _только_ работу с памятью не затронув
      все эти контексты.
      Ты же упорно говоришь про какое-то управление памятью в
      сферическом вакууме

      И что из этого следует ? Что работа с памятью грамотная ?
      Где логика ?

      Итого подводим итог, Руслан считает что:

      "
      - ЭЭЭ на джава 10050 томкатов и серверов и 20 лет истории

      - Огромная комьюнити, конференции и толпа разрабов

      - Внутри текущей реализации памяти Java все завязки на всю остальную
      экосистему JVM и отдельно что то изменить ну совсем нереально и
      ну очень тяжко - даже невозможно - и все будет просто похоже на СИ

      - Разработчики Оракл самые умные в мире - да кто я такой чтоб
      вякать

      - Все остальные компании закодили видоизмененные JVM но даже не осмелились выложить
      свои JDK

      "

      Из этого следует что работа с памятью в Java грамотная ? :))

      Логика железная.


      Удалить
    23. А по поводу предложений и коллектива

      Я когда пришел в ДБ - первое что я проорал на весь автобан
      - долой кибабмапу


      Ответ был гениальный:
      Да ты да тут до тебя да ваще да бля ....
      Вот тебе тулзень, гитхаб - пили - но чтоб две ноды встали и не парит

      Ну че - словили с1 - все нормуль

      В итоге все завелось - но потом народ таки допер -
      что кибабмапа неграмотная и ну совсем не стоит на ней что то новое лабать.

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






      Удалить
    24. Саша, я устал тебе что-то объяснять. Для меня очевидно, что ты то, что ты называешь грамотностью -- это чисто теоретическая конструкция. Как если бы волшебник вдруг махнул палочкой, и пересоздал бы джаву с 0 по лекалам сегодняшнего дня.

      Я же тебе объясняю, что такое понятие "грамотности" не имеет никакого практического смысла. Потому что волшебников не существует, и системы, подобные джаве, не создаются по мановению волшебной палочки -- они развиваются десятилетиями. И поэтому _состояние_ такой системы не может быть "грамотным" или "не грамотным" -- грамотными или нет могут быть только _решения_, которые двигают систему в каком-то направлении. И грамотность таких решений определяется не сравнением конечного состояния с абстрактным и умозрительным эталоном, а возможными _альтернативными решениями_. Грамотное решение -- это наилучшее из возможных тогда, при наличии той информации, что была доступна тогда. Здесь и сейчас ты можешь сколько угодно рассуждать о теоретической грамотности, но эти рассуждения не имеют никакого смысла, потому что они никак не подсказывают тебе _действия_. Решения, которые нужно предпринять, чтобы эволюция огромной и сложно связанной системы, которой является платформа джава, со всей своей инфраструктурой, сообществом и бизнес-моделями, двинулась в "правильном" направлении.

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

      Ты, возможно, еще не сталкивался с этим фактом, потому что до сих пор был "один в поле воин" -- мог реализовать "правильное" решение своими силами за ограниченное время. Ну, подумаешь, пару недель покодил по 16 часов в день, зато "грамотно" же вышло. Но сейчас мы обсуждаем решение, только для _технического_ воплощения которого тебе будет нужно пахать пару лет по 16 часов в день (и сначала еще повысить квалификацию). А техническая реализация здесь -- это только начало, как показывает случай Unsafe.

      И поэтому наш разговор довольно быстро сполз с технических деталей на философию: я вижу, что ты совершенно не думаешь об этих аспектах, которые здесь важнее технических. У тебя под носом пример Unsafe: уж чего проще, один-единственный класс из _приватного_ АПИ выпилить. Технической работы hotspot dev на пару часов. Однако сколько бурления, и сколько других, параллельных проектов (типа VarHandle) пришлось подстегнуть, и все это уже растянулось на два релиза, и может растянуться и больше. А ты предлагаешь на порядки более объемное изменение, и говоришь о нем так, как будто это пару недель покодить, и в продакшен.

      Удалить
    25. Этот комментарий был удален автором.

      Удалить
  8. Этот комментарий был удален автором.

    ОтветитьУдалить
  9. Этот комментарий был удален автором.

    ОтветитьУдалить
  10. выделение на стеке ( дотнет), почему нет?, имхо 9-10 не за горами,
    а если еще включат expression аки в дотнете, это взорвет джаву не по детский в лучшею сторону

    ОтветитьУдалить