Комментарии 26
Да уж. Я помню, в свое время были даже попытки создать жалезный процессор, способный исполнять байткод напрямую, picoJava например. Но вроде все это умерло.
Джава процессор это да, а лисп машину то как жалко!
Вы таки не поверите: https://en.wikipedia.org/wiki/Jazelle ...
Интересно, почему умерло? Понятно, что для ноутбуков или персональных компьютеров оно не подошло бы, но для каких-то железок встроенных, с микроконтроллерами - вполне. Роутер, там, на джаве.
Cranelift не пробовали прикрутить?
Нет, не слышал о таком.
Я так понимаю, это для оптимизации? Чтобы в рантайме генерировать машинный код под конкретный процессор?
Да, это что-то вроде LLVM, только на Rust. С ней довольно легко работать, надо просто не исполнять инструкции самостоятельно, а передавать их в библиотеку в понятном ей формате. Остальное библиотека сделает сама.
А еще интересно было бы решить обратную задачу — научить Rust компилировать в JVM. В первую очередь это позволит писать под Android на Rust.
Хм, а в чём преимущество?
И зачем будет нужен тот же borrow checker и контроль памяти при компиляции, если всё равно gc?
Преимущество — в возможности использовать один и тот же язык для написания под все платформы. Сейчас можно написать единый код на Rust для Windows, Linux, MacOS и WASM, но для Android и iOS приходится писать отдельно. Это очень неудобно и заставляет делать двойную или тройную работу. Независимые от платформы алгоритмы хочется писать отдельно.
Спасибо за ответ! Так да, звучит разумно.
Под андроид нельзя использовать скомпилированные c/rust библиотеки? Dll/lib
Использовать библиотеки можно, но очень неудобно. Приложения, использующие нативный код, рассматриваются как априорно опасные, им труднее попадать в магазины приложений и они попадают под всякие санкции со стороны самой операционной системы. К тому же только JVM-код может (с помощью библиотек) почти полностью абстрагироваться от версии Android, а нативный код должен разбираться в зоопарке версий и подставлять костыли. С совместимостью версий ОС на нижнем уровне в Android все плохо.
gc не заменяет контроль памяти, контроль памяти вообще для другого нужен. Он в первую очередь для того, чтобы исключить ситуации, когда написано не то, что задумано. Rust очень хорошо обнаруживает именно ошибки проектирования кода. Сборщик мусора в таких случаях гарантирует, что код не попортит память, но это еще не значит, что код не начнет творить дичь.
Вещи вроде "я ожидаю, что объект к этому моменту все еще будет находиться в списке" сборщик мусора решает плохо: он заставляет объект уничтожиться позднее, чем его вычеркнут из списка, хотя на самом деле речь идет о логической ошибке, когда объект просто слишком рано удаляют из списка. Сборщик мусора оказывает медвежью услугу, маскируя ошибку.
Но вообще интересно, да. Наверняка через тот же llvm как-нибудь можно.
А почему не взять и не реализовать машину для wasm какого-нибудь? Там и спеки попроще и до финала недалеко. А потом к этому компиль приклеить.
Дальше идёт ссылка на запись в constant pool, где хранится имя текущего класса (интересно зачем, ведь оно по текущему пути легко определяется...)
Рискну предположить, что для избавления от необходимости читать и разбирать текущий путь.
Ссылка допустима только одна, так что множественное наследование в принципе не предусмотрено в JVM.
По-моему тут маленькая неточность: множественное наследование запрещает JLS (спецификация языка), а не ВМ.
Дальше идёт ссылка на запись в constant pool, где хранится имя текущего класса (интересно зачем, ведь оно по текущему пути легко определяется...)
Ложки не существует, Нео!
Класс можно опредлить вызовом ClassLoader::defineClass() и никакого «текущего пути» у него не будет, а имя будет-таки. Такие классы многократно создаются за время работы программы, те же лямбды, к примеру.
Век живи, век учись! Спасибо.
Хммм, а "заменять" классы так можно?
Для модификации загруженного байткода есть интерфейс java.lang.instrument.Instrumentation.
Но его функциональность ограничена, можно лишь изменять тела существующих методов, новые методы или поля через этот механизм добавить не получится.
Один из примеров применения: https://habr.com/ru/company/odnoklassniki/blog/429040/
It is Wednesday, my java dudes, или насколько сложно сделать свою JVM