a_belyaev Dec 17 2018 at 18:06

Десять вещей, которые можно делать с GraalVM

22 min

44K

Haulmont corporate blog Programming *Java *Learning languages

Translation

+36

Comments 22

alexander_8901 Dec 17 2018 at 20:14

Звучит очень-очень заманчиво) Возможность подтянуть разные библиотеки из разных языков очень соблазнительна, правда как представлю проект, написанный 10-ю разными разработчикаи на 10-ти разных языках, который надо поддерживать, начинает глаз дергаться ..)

a_belyaev Dec 17 2018 at 20:20

Ну не обязательно же все свое писать, можно готовые подключать, как в случае графиков на R :-)

C4ET4uK Dec 17 2018 at 20:23

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

CyberSoft Dec 17 2018 at 21:12

Есть пример Spring + R (это демка с гитхаба). Spring вроде как использует рефлексию, или я ошибаюсь?

C4ET4uK Dec 17 2018 at 22:04

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

ris58h Dec 17 2018 at 22:15

в нативном образе нельзя использовать рефлексию

Я бы не был настолько категоричен.

C4ET4uK Dec 17 2018 at 22:41

Согласен, правильно будет «в нативной сборке использование рефлексии ограничено».
Но лично мое ИМХО — использовать рефлексию настолько неудобно, что можно сказать, что ее использовать нельзя.

Throwable Dec 18 2018 at 14:47

Бесполезен. Рефлексия очень глубоко вросла в Java и сильно савязана с Java runtime. Любой фреймворк или практически любая библиотека так или иначе завязана на рефлексию, а без своей экосистемы Java практически бесполезна. Рефлексия не позволяет компилятору вычислить статически все дерево вызовов и слинковать статически только используемый код, как это делает С например. Именно поэтому в Java 9 придумали модули — чтобы хоть как-то обязать пользователя объявлять статически границы, и чтобы финальный бандл можно было порезать с 200-300Мб до 30-40Мб.

Помимо рефлексии фреймворки еще делают такие безобразные вещи как classpath-scan, annotation processing и кодогенерация в рантайме, custom classloaders, etc… Так что много еще что отвалится.

C4ET4uK Dec 18 2018 at 14:54

Если мне нужно написать скрипт на 200 строчек и я знаю только java — то рефлексию я зачастую использовать не буду. Часто вы в утильных скриптах используете рантайм кодогенерацию и кастомные класслоадеры?

Throwable Dec 18 2018 at 15:38

Возьмите GCJ чтоли и будет вам счастье. GraalVM как бы не для этого.

hMartin Dec 17 2018 at 23:55

Получается, что нативный образ — это условный kotlin/native с сохранением большей части либ под jvm? Интересно, почему в него не смогли джетбрейнсы?

Dveim Dec 18 2018 at 14:52

Не совсем, KN представляет собой куда более узкоспециализированную и ограниченную штуку. А вообще, «давайте сделаем набор случайных несвязанных ad-hoc возможностей» — modus operandi котлина в целом.

vics001 Dec 18 2018 at 03:05

Помню было очень востребовано преобразовать java-code в native: а) чтобы не переписывать кучу кода б) чтобы получить преимущества native.

Все это упирается в то, что Java-код использует большую std-либу, как-то Calendar, Date, Locale, Collator (icu) — сложно представить программу c более 50К LOC, где не вылезет что-то такое. Так вот до GraalVM был многообещающий AvianVM c AOT: куча классных HelloWorld компилировалось, но нужный проект не взлетал, крешился при работе с данными и GС. Avian развивался 4 года, но так и не смог запустить не самую сложную Java программу, а потом похоже пропал интерес и все закончилось.

Хочется верить, что GraalVM не ждет участь неудачников, ведь написание AOT крайне сложная задача, особенно если мы говорим о кроссплатформенной генерации ASM. Прежде всего хотелось бы, чтобы GraalVM позволял компилировать Java-code и делать удобную линковку с C++ кодом туда и обратно. Если это еще можно будет скомпилировать через clang для мобильных платформ. наступит сказка.

Throwable Dec 18 2018 at 14:28

Был когда-то больше 10 лет назад вполне рабочий GCJ. Писали на нем и утилиты и серверы. Все летало, особых багов замечено не было. А 20 лет назад был Microsoft JVM, который поддерживал нативную линковку с DLL-ями, win32 API и ActiveX. Еще есть отличный Excelsior…
GraalVM ждет та же участь — мутное целевое использование, сильная завязанность на Java и ее ограничениях, запоздалость. Сейчас грядет WebAssembly, компиляторы в него из разных языков, затем его выпустят как отдельную VM.

acmnu Dec 18 2018 at 09:07

Нативный бинарник? Черт, я впервые почувствовал непреодолимое желание написать что-нибудь на Java. Это на столько хорошо, что не верится.

potan Dec 18 2018 at 11:53

Забавно было бы сделать на нем JIT .net…

a_belyaev Dec 18 2018 at 15:01

Так берешь Truffle и строишь AST из C# — и будут программы, написанные на C# запускаться :-) Можно ещё попробовать CIL напрямую подсовывать в GraalVM, но это посложнее.

potan Dec 18 2018 at 19:45

Раз jvm и llvm поддерживаются, значит байткод туда тоже тоже можно засунуть. Просто C# не так интересно, хочется вызывать F# и Nemerle из Scala.

alatushkin Dec 18 2018 at 12:44

Есть информация по поводу нативных образов из других языков с биндингами?

Просто тот же python конечно хорош, но часто его польза в большом количестве библиотек с привязкой нативных библиотек

a_belyaev Dec 18 2018 at 14:54

Там как раз написано, что bitcode может выполняться совместно с python. Но совсем нативные образы не получится слинковать, мне кажется. Но, если библиотеки перекомпилировать, то должно все получиться.

boiler5 Apr 28 2019 at 06:00

Первый проделанный эксперимент с подсчетом слов в лорем ипсуме не дает никакого прироста скорости. Запускаю на ноуте.

SharplEr Sep 16 2019 at 13:23

TopTen написан не оптимально:

.flatMap(line -> Arrays.stream(line.split("\\b")))
                .map(word -> word.replaceAll("[^a-zA-Z]", ""))

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

Collectors.counting

— аллоцирует Long на каждый инкремент (по крайней мере в Java 8). Знаю это довольно позорно, но это так. Тут либо можно написать свой MutableLong и реализовать редьюсер самому, либо взять сторонний Object2LongMap где можно эффективно инкрементить значения.
Ещё связка sort().limit(10) — у меня нет уверенности что там используется какой-то эффективный алгоритм, скорее всего сортируется вся последовательность целиком. Самый быстрый способ на коленки сделать лучше: положить все ентри в PriorityQueue (внутри там бинарная куча на массиве) через конструктор, а потом достать первые 10 элементов. Фокус в том, что можно за линию собрать кучу из массива. Главное не добавлять элементы по одному. Можно реализовать с помощью к-той порядковой статистики алгоритм эффективнее по памяти но это немного муторно.