Компания Oracle анонсировала (https://blogs.oracle.com/developers/announcing-graalvm) первый релиз проекта GraalVM (http://www.graalvm.org/), в рамках которого развивается универсальная виртуальная машина для запуска приложений, написанных на JavaScript (Node.js)), Python, Ruby, R, любых языках для JVM (Java, Scala, Clojure, Kotlin) и языках для которых может формироваться биткод LLVM (C, C++, Rust). Код проекта https://github.com/oracle/graal распространяется под лицензией GPLv2. Выпуск 1.0 пока имеет статус (https://github.com/oracle/graal/releases) кандидата в релизы.
GraalVM изначально развивалась как универсальная виртуальная машина, способная обеспечить высокопроизводительное выполнение кода на любых языках программирования и предоставляющая средства для организации взаимодействия между кодом на различных языках программирования, давая возможность создавать комбинированные приложения с компонентами на разных языках.
Вместо преобразования структур данных в подобных программах, GraalVM позволяет (https://github.com/oracle/graal/blob/master/truffle/README.md) непосредственно обращаться к объектам и массивам из других языков, убирая изоляцию между языками и позволяя использовать общий runtime. Например, из JavaScript-кода для Node.js можно обращаться к библиотеке классов Java или из кода на Java вызывать функции обработки статистики на языке Python, или запускать код на языке R для создания сложных SVG-графиков. Используя GraalVM программист может сочетать разные языки, выбирая язык наиболее подходящий для каждого вида задач.
GraalVM может применяться как обособленно, так и как часть платформ, подобных OpenJDK и Node.js, или даже встраиваясь как движок обработки данных в СУБД, такие как MySQL и Oracle. Для запуска приложений предлагается стандартизированное окружение для выполнения.
GraalVM предоставляет JIT-компилятор, который может на лету выполнять в JVM код любых скриптовых языков, включая JavaScript, Ruby, Python и R, а также даёт возможность запускать нативный код в JVM, преобразованный в биткод LLVM. Предоставляемый GraalVM инструментарий включает независимые от языков программирования отладчик, систему профилирования и анализатор распределения памяти.Для языков на базе JVM имеется возможность создания предкомпилированных нативных образов, которые можно выполнять напрямую с минимальным потреблением памяти. Для создания таких исполняемых образов применяется предварительный статический анализ для выявления всего кода, который охватывает выполнение основного Java-метода, после чего к этому коду применяется (https://github.com/oracle/graal/blob/master/substratevm/READ...) полноценная упреждающая компиляция (AOT, ahead-of-time). В результате формируется исполняемый файл, включающий машинный код приложения, готовый к незамедлительному выполнению без лишних прослоек, таких как JVM.
URL: https://blogs.oracle.com/developers/announcing-graalvm
Новость: https://www.opennet.me/opennews/art.shtml?num=48472
Т.е. без жабы оно всё-таки не работает?
http://www.graalvm.org/docs/ :> GraalVM 1.0 is based on JDK 8.
> GraalVM includes the following components:
> Oracle HotSpot Java Virtual Machine (JVM): A runtime environment for JVM-based languages and supported guest programming languages.
Частично. Пара языков и связки язык<->язык требуют жабу
Хипсторы счастливы.
Это только пока они не попробовали на практике скрестить жабу с гадюкой. А когда попробуют - Наполеонов резко прибавится. Потому что у разных ЯПов разные подходы к типизации, объектам и проч. И когда они со всей этой фигней попробуют взлететь...
https://github.com/oracle/graal/blob/master/substratevm/LIMI... скормить этой штуке древний код и получить конфету не выйдет. Очень много «но».
SubstrateVM это тупая запускалка для языков без мощного рантайма. Единственное, что на ней должно работать, это написанные на Java компоненты самого Graal.Для AOT-компиляции существующего Java-кода логичнее использовать нормальный AOT, реализованный в Java 9: http://openjdk.java.net/jeps/295
Несомненно это прорыв в IT
Ничего нового, до него уже была попытка сделать ParrotVM.
>Ничего нового, до него уже была попытка сделать ParrotVM.Вот именно попытка. А Oracle которого все поносили, СДЕЛАЛ!
> Вот именно попытка. А Oracle которого все поносили, СДЕЛАЛ!Вообще-то первый релиз со стабилизацией API был в далеком 2009 году. Последний стабильный релиз 8.1.0 появился 16 февраля 2016 года. Так что ParrotVM вовсе не попытка, а работоспособный. Если сравнивать их, то у ParrotVM заявлен более внушительный список поддерживаемых ЯП. Но как и с GraalVM, много чего пока поддерживается частично. Тут вообще говоря невозможно остановиться и сказать что XyzVM поддерживает конкретный ЯП до конца, т.к. ЯП тоже обрастают новыми возможностями.
Ладно, это не важно. Важно чтобы ты понял что пора переставать пустозвонить!
> Вообще-то первый релиз со стабилизацией API был в далеком 2009 году.И чего с тех пор добились разработчики ParrotVM? Производительности выше, чем у JVM, PHP 7, v8? Изящного дизайна? Полной поддержки языков?
Под JVM тоже много лет пытались делать порты других языков. Некоторые оказались относительно успешными (см. JRuby, Clojure), другие давно забыты. Во всех случаях, основным камнем преткновения был FFI, — без возможности грузить нативные библиотеки пользы от портирования Python или Node.js не так много. *Частичную* поддержку можно заявлять до бесконечности, но на ней всё и заканчивается. ParrotVM/pynie как начала с "частичной" поддержки Питона, так на ней и осталась.
Graal позволяет подключать библиотеки на C/C++ (через sulong/LLVM) и напрямую выполнять байткод поддерживаемых языков (вместо компиляции в свой байткод, как у ParrotVM). Это на порядок снижает затраты на поддержку и добавление новых возможностей языков.
> ParrotVM/pynie как начала с "частичной" поддержки Питона, так на ней и осталась.
> Graal позволяет подключать библиотеки на C/C++ (через sulong/LLVM) и напрямую выполнять байткод поддерживаемых языков (вместо компиляции в свой байткод, как у ParrotVM). Это на порядок снижает затраты на поддержку и добавление новых возможностей языков.Эм. И что, это и правда поможет загружать питоновские расширения, где есть C-шный код? Который, напомню, подразумевает ручное управление памятью и инструкции для GIL, специфичные для CPython реализации?
Не вижу разницы с ситуацией с ParrotVM, проблема вовсе не в FFI и невозможности подгрузки библиотек, а в том, что спецификация Python C API для расширений тесно связана с реализацией CPython.
>это прорыв в ITВызывайте скорей сантехников, иначе эту IT потом не отмоем.
>>это прорыв в IT
> Вызывайте скорей сантехников, иначе эту IT потом не отмоем.Дык сантехники нынче в оракле как раз и работают же!
Новости об оракле внимательнее читай: всех сантехников почти сразу и уволили оттудова
где php!?
> где php!?в ж
Facebook уже пытался писать новую VM для него. Результат на лицо
нормальный был результат. просто с выходом php 7 нужность hhvm сильно снизилась.
> нужность hhvm сильно снизиласьВот-вот. Кто в здравом уме будем адаптировать VM для языка, чтобы через год её нужность "сильно снизилась"?
основной задачей фейсбуковского пхп было повышение производительности и строгая типизация. и то и другое завезли в php 7.
у фейсбуковского пхп в преимуществах остался jit и hack.
jit в обозримом будущем должны завести в оригинальный пхп.
лицензионных ограничений, которые могли бы побудить использовать hhvm а не zend engine не наблюдается.
---
так что эта ваша подростковая мода хейтить пхп не имеет под собой, в данном случае, оснований.
Ну да, на лицо - Face же book!
>> где php!?Не надо ругаться! Пожалуйста.
Теперь софт будут писать еще более упoрото. Сверху еще докер нужен!
> Теперь софт будут писать еще более упoрото.Разве это возможно?
Есть поверхностое мнение, что GraalVM предоставляет для упoротой разработки просто безграничные возможности.
Люблю упорοтую разработку! Даёшь поддержку brainfuck!
держи, шутник :-)
https://github.com/chumer/bf
> Сверху еще докер нужен!Нет. Докер - он снизу!
>> Сверху еще докер нужен!
> Нет. Докер - он снизу!Докер, он в головах. :/
Осталось добавить веб-интерфейс и получится beaker-notebook?..
>высокопроизводительное выполнение кода
>based on JDK
JIT в мирке анонимуса еще не изобрели, жаль.
Вообще-то неплохо бы знать, JIT, да ещё и с оптимизацией - адски дорогая штука, оправдывающая себя сильно не везде.
Поэтому JIT там многоуровневый с разной степенью оптимизации и стоимостью компиляции (см. tiered compilation).
Именно. Для постоянно крутящегося чего-то - нормально, а для того, чтобы быстро запустить и прибить (от утилит до микросервисов) - не особо. В остальном - собственно, довольно живые реализации всей этой скриптятины и не только её под jvm и раньше были, и взаимодействовать тоже могли.
> Поэтому JIT там многоуровневый с разной степенью оптимизации и стоимостью компиляции (см.
> tiered compilation).Ну то-есть получается какая-то оверинженернутая энтерпрайзятина, по типу жабы, где один только запуск программы ждать заманаешься :)
> JIT в мирке анонимуса еще не изобрели, жаль.Глядя на то сколько вкалывает gcc -O3 с LTO чтобы выдать нормальный уровень оптимизации - я как-то не очень хочу чтобы при запуске каждой программы все встревало на столько же. Значит, оптимизация будет хуже.
В смысле, в случае gcc оно тормозило 1 раз и где-то там. Возможно даже не у меня а на могучей билдферме у майнтайнеров системы вообще. А тут разрываться между вклином на дофига или тупняками неоптимизированного кода будет уже именно мой компьютер и это как-то без вариантов. Так что подход понравится разве что фанатам "приложений на электроне". Нуакули, в электроне JIT есть!
Хорошая попытка, орки, но нет, гугл теперь на ваши сраные патенты ни ногой.А так действительно грааль.
Грааль зделали 50 лет назад: i8088
Он всё это умел)
https://ru.wikipedia.org/wiki/8088#/media/File:I8088.jpg
Клоуны)
> зделалиТы должен мне новые глаза. Даже если это было в шутку.
Oracl уже показал свои патентные замашки, будут жить в своем виртуальном мирке в одиночестве
А я считаю, что гугл получил по заслугам. Он добровольно-принудительно выуживает всю персональную инфу, до которой его вонючие щупальца только могут добраться. Столлман все-таки был прав. Да-да, я знаю, сейчас набегут и расскажут, как зонд приятен и удобен ))
Ну есть же репликанты всякие. А вообще смартфоны by design зонды, как и любые сотовые телефоны. Даже если предположить что будет 100% свободная прошифка радиомодуля и вообще всех SoC в телефоне - сотовые станции то проприетарны и что там делает оператор с твоими данными ты не знаешь.
Это end-to-end шифрованием решается, а собственно телефонный голосовые звонки - для смартфона уже практически побочная функция.
> Это end-to-end шифрованием решается, а собственно телефонный голосовые звонки - для
> смартфона уже практически побочная функция.Ага, ты в курсе что с 1 июня все звонки сохранять будут? Ну так вот, отсеять твои шифрованные сообщения раз плюнуть. Не выделяйся из толпы - будь толпой.
> Ну так вот, отсеять твои шифрованные сообщения раз плюнуть.И, собственно, чего? Потребуют ключи? Блин, у меня их нет. И вообще, они эфемерные и давно убиты. Запретят крипто? Тут же хакеры все раздолбают, да и на запрет легко положить путем использования стеганографии.
нет, не по заслугам. Патенты на апи к гуглослежке почти никакого (кроме совсем косвенного) отношения не имеют и нарушают права всех нас.
Как минимум заманчиво.
И все это с native-компилляцией. Класс.
У меня helloworld получился на 7 мегабайт. Стоит это учитывать
Всего 7мб. С бесплатным Excelsior JET у тебя получиться 100мб helloworld, а с платным и очень догорим около 40
У бесплатного JET получилось 140 килобайт. Но даже если бы у него действительно было бы 100мб, это бы не означало, что 7 мб -это хорошо.
И где ты найдёшь JIT-компилятор плюс GC меньше 7 мб?
> И где ты найдёшь JIT-компилятор плюс GC меньше 7 мб?GC мало занимает, а JIT туда не включён, судя по ограничениям - https://github.com/oracle/graal/blob/master/substratevm/LIMI... , но можете привести ссылку где указано, что включён. Только что бы это изменило? Зачем это нужно в любом приложении?
> GC мало занимаетТолько тупой GC с минимумом настроек. В HotSpot их десяток из коробки
> JIT туда не включён, судя по ограничениям... , но можете привести ссылку где указано, что включён. Только что бы это изменило? Зачем это нужно в любом приложении?
В Android тоже пытались полностью переехать на AOT. Как выяснилось, — качество оптимизации — дно, а пользователи не очень рады ждать два часа пока их приложение приготовится к запуску. В последней версии Android впопыхах прикрутили гибридный JIT поверх AOT.
> substratevm/LIMI
Не конкурент Excelsior JET. Сравнивать с Excelsior нужно нормальную JVM с поддержкой AOT, добавленной в Java 9. И не на Hello World, а на нормальном приложении, использующем что-то кроме System.out.
Во время моего знакомства с JET, он оптимизировал на основе профилей (compact1, compact2, compact3…) И как только заходила речь о чём-то сложнее Hello World, подключение пары дополнительных профилей быстро раздувало размер дистрибутива до десятков мегабайт.
Минимальный профиль у jet 14 без всего занимает 30 с чем-то мб и еще сам исполняемый файл
бесплатная же версия профили не поддерживает и среда для запуска около 100мб занимает, так как там все включено.>Не конкурент Excelsior JET
я очень надеюсь что не конкурент, потому что таскать 100мб библиотек к маленькой консольной программе не хочу.
>> GC мало занимает
> Только тупой GC с минимумом настроек. В HotSpot их десяток из коробкиВ среде для запуска разных приложений - это оправдано, в отдельно собранном приложении - это не нужно. Речь идёт, если Вы не заметили, не о HotSpot, а о Substrate.
> В Android тоже пытались полностью переехать на AOT
При чём тут Android? Вы понимаете разницу между доставкой Java приложений пользователю и компиляцией в машинный код на его стороне и компиляцией в машинный код на стороне разработчика и доставкой пользователю уже в готовом виде?
>> substratevm/LIMI
> Не конкурент Excelsior JET.Я и не говорил, что они конкуренты и не сравнивал, но Вы, похоже, этого не заметили. Я лишь ответил на конкретный рассказ про 100мб на helloworld.
> При чём тут Android?Это я к тому, что все крутые ребята переезжают на AOT + JIT (или JIT с кешированием результата). Голый AOT или не позволяет оптимизировать по максимуму (при отсутствии closed-world assumption) или не позволяет грузить сторонние библиотеки (как это сейчас имеет место в substratevm).
В Android сильный closed-world assumtpion: DexClassloader существует, но практически не используется. В вебе наоборот — левые библиотеки грузятся на каждом шагу, но польза от кеширования все жё есть. В реальных Java-приложениях ситуация обстоит похожим образом.
Когда я пытался использовать Excelsior JET, у меня было с ним две проблемы:
1) Долго стартует
2) Сгенерированный код не слишком быстрыйЕсть подозрение, что оба пункта (особенно п. 2) — прямые следствия перечисленных выше проблем AOT-компиляции.
ну покажи helloword скомпилированный в jet на 140кб
Попробуйте сами https://www.excelsiorjet.com - это не сложно.
То есть сделать hello world в jet на 140кб ты не можешь. Приходит когда получишь исполняемый файл вместе со средой для его запуска хотя бы меньше 20мб
Могу, конечно. Просто Вам никто ничего не обязан. Попробовали бы сделать сами и убедились бы в лучшем виде.
Я пробовал excelsior jet и знаю о чем говорю. Но Вы продолжайте доказывать что ничего не можете
> Я пробовал excelsior jet и знаю о чем говорю.Когда именно Вы пробовали?
Пора переписывать с Electron на жабу? :D
а как бугуртили 20 лет назад из-за того что Delphi создает helloworld ы размером целых 600 килобайт. Прогресс.
Там реализация классов емнип много занимает. Я попробовал и написал на winapi в c++ builder и исполняемый файл был небольшой.
И как в этой программе идёт разделение доступа к железу? Полное отсутствие доступа ??
Не хватает поддержки .NET ))
Ни слова про clr. Дот нет идёт сторонкой?
> Ни слова про clr. Дот нет идёт сторонкой?Слишком отличный от явы лучший конкурент явы. А ява внезапно оракловская и машина сделана поверх явы.
https://github.com/oracle/graal/issues/349A C# and .NET interpreter on top of Truffle would be absolutely possible. You can either implement it as a full AST interpreter specialized for C# (similar to Graal.js) or you could implement a Bytecode Interpreter for CLR bytecode (similar to Sulong). The second approach would probably be simpler and would also get you support for other CLR languages.
Currently we have nobody working on it. But we are an open platform ;-).
---------------------
We would actively support such an effort. Also, we could create internships for students with .NET assembly experience for getting it started.
Математики ∆етекте∆.
Объекты не "языков", а "рабочих сред реализаций языков".
Признаться, смысла всей этой затеи я не понял, если это работает с байткодом одного лишь llvm.
Это работает поверх HotSpot, который отрефакторили для поддержки динамических языков с *любым* байткодом.Вся соль в том, что HotSpot ценой безумных затрат допилили чтобы его GC можно было использовать отдельно от библиотеки классов Java (или если посмотреть с другой стороны — вынесли JIT-компилятор в отдельную библиотеку, которую теперь можно реализовать с помощью LLVM).
> Это работает поверх HotSpot, который отрефакторили...Спасибо, но всё равно не ловлю смысла. Для этого, наверное, нужно "вариться" в реалиях штатовского рынка информатики.
Зачем что-то понимать в реалиях рынка?JDK-ная виртуальная машина рефакторилась-рефакторилась, пока внезапно не начала выполнять байткоды LLVM, руби, питона и ещё черт знает чего.
Т.к. имидж оракла немного подмочен, а бренд жабы слишком тесно связан с конкретным языком/байткодом, менеджеры быстренько провели ребрендинг: JavaVM -> GraalVM. Никто ведь при обсуждении nodejs всерьёз на вспоминает про v8 (хотя 90% технической сложности рантайма сосредоточено в нём, а создатели ноды имеют к его разработке весьма косвенное отношение). Так и здесь, — Graal пытаются позиционировать как рантайм для динамических языков (способный работать поверх HotSpot, но это уже детали). Раньше такое тоже можно было делать, но в итоге приходилось всё компилировать в байткод жабы, а из всех щелей торчали потроха жабных фреймворков. Теперь внутренняя реализация стала красивее, только и всего.
Никакого рынка там сейчас нет, — просто *плановый* рефакторинг JDK привёл к появлению новых перспектив, чем-то извне напоминающих последние подвижки с Perl 6 и WebAssembly.
> Зачем что-то понимать в реалиях рынка?...
> Т.к. имидж оракла немного подмочен, а бренд жабы слишком тесно связан с
> конкретным языком/байткодом, менеджеры быстренько провели ребрендинг: JavaVM -> GraalVM.Ну так вот же они, реалии рынка. Спасибо за инфу.
>The Graal Polyglot API lets you embed and run code from guest languages in JVM-based host applications.Вне Java мира бесполезно, все кто пишет на нативных языках (или оно умеет мост к C API) и хотел встроить сие чудо чтобы можно было писать дополнения для своего приложения
на любом из перечисленных выше языков можете вместе идти лесом.
А дальше первого абзаца не пробовал читать?Одна из ключевых фишек Graal — динамическая генерация биндингов к сишным либам. Которые в отличии от JNI имеют прямой доступ к памяти и могут использоваться в любых поддерживаемых динамических языках.
Проще говоря, это гибкий, многоязычный FFI, который лучше FFI питона, ноды и руби вместе взятых. И который в отличии от ParrotVM ещё и работает.
То есть использования (LLVM) C/C++/Rust (Experimental) R/Python/Ruby из JVM под одним удобным API. Как без JVM пришить одновременно Python/Rust/C++ для дополнений к приложению (которые работают в песочнице) на чистом C?
А в чём принципиальная выгода от "без JVM"? Плагину на Python/Ruby/Javascript всё равно нужны сборщик мусора и JIT. Если ты будешь руками прикручивать виртуальные машины этих языков к своему процессу, ты получишь N виртуальных машин в одном процессе, каждая со своей кучей, своим рантаймом, служебными потоками, сборщиком мусора… И взаимодействовать между ними ты сможешь только через C ABI. Graal позволяет загрузить рантаймы этих языков (которые для этого должны быть установлены) в одну, общую виртуальную машину, которая уделывает по качеству и функционалу стандартные VM этих языков. И взаимодействовать с ними через высокоуровневое объектно-ориентированное ABI, предоставляемле GraalVM (aka JVM). "Без JVM" эта схема просто не реализуется, т.к. JVM выступает в качестве замены всех остальных VM.
Мне нужно чтобы берешь graalvm.h, используешь вот эти вызовы из C++ чтобы пнуть свое API в виртуальную машину, но чтобы работал именно язык X не забудьте установить Y который также можно тащить со своим приложением, предварительно выставить ENV со значением Z=APPDIR.JS вшить что через MozJS (правда с голым C API оно мне больше нравилось), что с V8 не сложно вообще. И всего-то одна библиотека. Python, делал через Boost но все же, также ничего сложного, да тащить runtime. Dart - около V8. Lua - тоже ничего особенного. LLVM Bitcode - довольно интересно и начать не так уж и много занимает - C, C++, Rust, D тут же. Mono - немного поиграть и уже можно работать. На изучение любого из методов не требуется много времени, практически везде можно встретить как это встроить в C/C++ чуть ли не со стартовой страницы.
А что с этим? Вот как вшить в Java (или любой JVM язык), вот есть пересобранные Node.JS/R/Python/LLVM где вы можете вызвать сие чудо из друг друга. А где как вшить в C/C++ и начать работать как человек? Целый сайт восхваляющий сам себя и JVM, а для простых смертных думай как оно работает просматривая как переделали Node.JS в их репозитории что-ли?
> А где как вшить в C/C++ и начать работать как человек?Загружаешь разделяемые библиотеки JVM в своё приложение с помощью Invocation API: https://docs.oracle.com/javase/7/docs/technotes/guides/jni/s.... Собственно, именно так и работают все запускалки, поставляющиеся с Граалем. Само Invocation API существует уже лет 20.
Сам Грааль реализован как JIT-плагин к JVM. Т.е. грузишь ещё пару разделяемых библиотек самого Грааля.
Дальше — в зависимости от рантайма. К примеру, Грааль и Нода интегрируются путём замены v8 на реализацию на основе Грааля: http://mail.openjdk.java.net/pipermail/graal-dev/2017-Decemb... Т.е. грузишь модифицированный билд рантайма ноды, а он уже будет использовать Грааль вместо дефолтной VM.
Я бы тоже не отказался от адекватной инструкции, но к сожалению, разработчики Graal ближе к категории яйцеголовых академиков, чем к программистам, так что желающим в нём копаться придётся разбираться самостоятельно. Как я понимаю, изначальной целью было помочь существующим JVM-языкам (Jython, JRuby и т.п.) сделать нормальную интеграцию без полной пересборки под байткод JVM. Как следствие, они там очень смутно понимают, что может быть нужно остальной целевой аудитории.
Либо у них там AI либо на управлении памятью оно один хрен сломается за исключением простейших случаев и придётся-таки вручную эти биндинги делать. Второя, понятно, как-то вероятнее.Во-вторых - нормальные люди не тащят один модуль из одного языка, второй - из второго, третий - из третьего, на разных языках обычно разные компоненты приложения. А между ними один хрен нужне отдельных хорошо спроектированный API, в нынешних реалиях - предпочтительно сетевой.
В общем, очередной странный зверёк, на которой, конечно, из-за именно Оракла может повестись, но техническая осмысленность не очевидна.
> Либо у них там AIНе AI, а просто нормальный JIT и гибкое внутреннее представление кода
> Во-вторых - нормальные люди не тащят один модуль из одного языка, второй - из второго, третий - из третьего
Ты это серьёзно? Т.е. если я сейчас посмотрю на зависимости nginx или php-fpm, там не будет каши из С, С++, Javascript, Lua… И это в *серверном* коде. Не говоря уже про какой-нибудь QT5 или GTK3, где Javascript-интерпретатор требуется каждому графическому приложению для отрисовки надписей на кнопочках.
Сейчас вся эта лажа связана примитивными сишными API, и в идеале *слегка* оптимизируются динамическим загрузчиком (хотя там такие оптимизации, в которых вообще не должно быть надобности). Процессор, конечно, пытается что-то внутри себя поправить при компиляции в свои микроинструкции, но только в пределах размера своего кодового кеша, который не резиновый (да и нет у проца времени чтобы делать продвинутые оптимизации).
А представь, как было бы круто, если бы виртуальная машина могла понимать нативный код? И не рассматривать его как чёрную коробку с входным и выходным отверстиями, а инлайнить и оптимизировать между модулями и динамическими библиотеками.
> Либо у них там AI либо на управлении памятью оно один хрен сломается за исключением простейших случаев и придётся-таки вручную эти биндинги делать. Второя, понятно, как-то вероятнее.Наикрутейший GC предложенный еще в 2000-х мог уже тогда мог обеспечить трассировку объектов в рантайме в гетерогенной среде. Но сколько это съедает ресурсов.. По барабану сколько уходит памяти - можно свопиться при желании. Главная проблема - неоправданная утилизация процессорного времени резолвера. Кто "тыкал" это вживую, тот хорошо чувствует момент когда в JVM просыпался GC :)
А теперь наикрутейший GC крутится на мобильнике. И в ядре Linux (аж в нескольких местах). И по прежнему сжирает слишком много ресурсов.Почему-то все считают, что можно взвалить на GC тяжёлую работу, и он при этом будет работать лучше, чем malloc. И сами разработчики сборщиков мусора подбрасывают дровишек, — мол GC теперь всесильные, работайте с памятью не задумываясь. А потом удивляются, почему у них плохая репутация.
При этом в веб-серверах и реалтаймовых приложениях используется скриптинг на интерпретируемых (!!) языках с GC и ничего — всё прекрасно работает, если не делать аллокации в критических кусках кода. Так что, дело наверное не в GC и не в гетерогенных средах.
Столкнулся недавно с тем как Python GC стух при увеличении количества объектов и это со __slots__ и без. Картина примерно одинаковая. Попробую еще поэкспериментировать.
> А теперь наикрутейший GC крутится на мобильнике. И в ядре Linux (аж в нескольких местах). И по прежнему сжирает слишком много ресурсов.Ты не в теме вообще.
> и реалтаймовых приложениях используется скриптинг на интерпретируемых
> (!!) языках с GC и ничего — всё прекрасно работает, еслиЧто, управлялку движков гироскутеров уже на ЖС/питоне/пыхе делают? И как успехи?
> Что, управлялку движков гироскутеров уже на ЖС/питоне/пыхе делают? И как успехи?Как, как. Те кто посообразительнее - вопят про реалтайм с безопасного расстояния. Те кто менее сообразительный - давится мацой^W смузи.
Какой идиот писал эту новость? GraalVM - это JIT-компилятор для JVM. Без JVM он не будет работать вообще. А то расписал так, что как-будто создали новую виртуальную машину.
Это такая толстота, да?
> GraalVM - это JIT-компилятор для JVM. Без
> JVM он не будет работать вообще.Будет, он может в бинарники компилировать и использовать Substrate VM.
JIT-компилятор - это лишь _один_ из компонентов GraalVM, а JVM - лишь одна из возможностей запуска.
Там ещё есть AoT-компилятор, упрощённый Substrate VM, runtime, SDK, фреймворк Truffle и ещё куча всего.> А то расписал так, что как-будто создали новую виртуальную машину.
Oracle официально именует GraalVM виртуальной машиной. "Today, we are pleased to announce the 1.0 release of GraalVM, a universal virtual machine designed for a polyglot world." и далее по тексту именует "GraalVM is a universal virtual machine".
Грааль? Серьёзно?
> Грааль? Серьёзно?Grail-shaped beacon. Nasty, nasty Zoot!
Ну нагло, да
Очень здорово. Можно использовать библиотеки которых нет в java но есть на другом языке и компилировать в исполняемый файл.
> GraalVM предоставляет JIT-компилятор, который может на лету выполнять в JVM код любых скриптовых языков, включая JavaScript, Ruby, Python и R, а также даёт возможность запускать нативный код в JVMДопустим базовые команды языков заработают.
Теперь кто реализует библиотеки, включая криптографию и GUI на всех этих языках в этой виртуальной машине?
Никто, существующие библиотеки просто работают
Как собрать нативный исполняемый файл с помощью maven?
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>${env.GRAALVM_DIR}/bin/native-image</executable>
<arguments>
<argument>-jar</argument>
<argument>target/${artifactId}.jar</argument>
</arguments>
</configuration>
</plugin>пока так, как бы это сделать по человечески
И как у этого со скоростью для питона? В сравнении с pypy и со штатным питоном.
Да, так же херово будет. Это же VM. И в случае если штатный PythonVM хотя бы имеет предсказуемые таймауты на GC при выходе из функций, то JavaVM будет блочить мир. И Ваша аппликух апериодами будет подвисать, а выделение памяти при запуске отождрет сразу под 2 гига памяти. Хотя это предположения.
Можно поподробнее про предсказуемые таймауты?
Ошибка Oracle в том, что они решают проблему, которая в целом не стоит перед разработчиками.Разработчики на Node.js, cPython и Ruby прекрасно существуют без единого VM с другими правилами и вполне довольны своим окружением.
Писать на Python например без понимания как же работает этот самый VM опасно, так как непонятны ситуации с GIL и блокировками в сторонних библиотеках.
Короче говоря в языке почти самое главное это его Runtime, который по сути у многих и ассоциирован с языком, а попытка наклеить на JVM новые наклейки выглядит как ребрендинг просто уже существующих ScriptEnginie в Java для поддержки JavaScript и т.д.
Кому надо тот уже освоил Java, Scala, Gradle/Groovy, Kotlin и все у них хорошо, так как почти все области есть и динамический и функциональный подход.
> …проблему, которая в целом не стоит перед разработчиками.Согласен. К счастью, Грааль писался не для разработчиков на Node.js. Просто так случилось, что следующее поколение Java-рантайма оказалось на порядок гибче существующих виртуальных машин. То, что нашлись желающие в свободное время прикрутить его к ноде, это только на руку Ораклу.
> Разработчики на Node.js, cPython и Ruby прекрасно существуют без единого VM с другими правилами и вполне довольны своим окружением.
Очень спорное утверждение. Каждый месяц вижу на stackoverflow программистов на ноде, клянчащих нормальную многопоточность. И питонистов, пытающихся обойти GIL. Прикрутить GIL поверх JVM не сложно, а вот открутить его от питона :)
Просто, когда люди начинают писать код, они обычно не руководствуются рациональными соображениями (да и не знают ещё ничего, чтобы сделать осознанный выбор).
"У меня Android-смартфон — изучу-ка я Java!"
"В универе ничему кроме питона не учили, а здесь как раз вакансия с ним…"
"Java — тормозное г-но, буду писать на Erlang/PHP/Node.js!"А потом привыкают, находят в изученном языке свои плюсы. Когда эти разработчики вырастают, некоторые из них станут писать библиотеки для этих языков. И получается, что в Java тошнотворный API для работы с асинхронными сокетами, а в Node.js — превосходный (и десятки библиотек под него). Так что ничего удивительного в том, что кому-то пришло в голову портировать ноду на Graal.
Я уже вижу проекты где код на скале будет разбавлен кусками грязных хаков на JavaScript, потому что джуниоры знали только его.