Узнать больше о JRuby от Чарльза Наттера

Для стандартных фрагментов, таких как базовые классы String и Array, по большей части то, что написано на C в обычном Ruby, написано на Java для JRuby. Это основы. Кроме того, у нас есть интерпретатор, похожий на Ruby 1.8, который по сути просто прогуливается по дереву, абстрактному синтаксическому дереву (AST), которое было проанализировано из кода.

У нас есть парсер, который в основном является портом парсера Ruby, использующий аналогичный генератор парсера. Руби использует тот, который называется Бизон ; мы используем тот, который называется Jay, который по сути та же самая грамматика, тот же синтаксис, и наш парсер выглядит почти так же, как Ruby.

Чем отличаются Ruby 1.8, Ruby 1.9 и JRuby при разборе и выполнении вашего кода

Мы интерпретируем это какое-то время, просто ходя по нему и делая то, что говорит AST. Если фрагмент кода запускается много раз, то мы делаем еще один проход и компилируем его в байтовый код JVM. Я думаю, что порог составляет около 50 вызовов, и мы превратим его в байт-код JVM. Оттуда это до JVM. У JVM есть собственный цикл интерпретации на некоторое время, а затем компиляции в нативный код. Но в основном мы стараемся передать код JVM как можно быстрее, чтобы в какой-то момент все скомпилировалось до нативного.

Q: Я много слышал о «InvokeDynamic» в последнее время, и о том, как он ускорит JRuby, но я не уверен, что это такое. Можете ли вы объяснить, что на самом деле делает InvokeDynamic?

Основы вызова метода Ruby: если вы вызываете метод «foo», вам нужно найти фрагмент кода, который идет вместе с методом «foo» для некоторого целевого объекта, а затем вызвать его. В идеале, вы не хотите делать такой поиск каждый раз, когда вызываете foo, так как может потребоваться обход иерархии классов, между вызовом и целевым классом могут быть некоторые сложные модули и другие вещи. Итак, вы хотите как-то это кешировать. Типичный способ, которым Ruby 1.9, JRuby и некоторые другие реализации делают это, заключается в том, что называется встроенным кэшем. В каждой точке кода, где вы делаете вызов, у нас есть небольшой кеш, который сохраняет последний увиденный метод. Если вы продолжаете вызывать один и тот же метод в этот момент, снова и снова, он не будет продолжать выполнять поиск. Вот как работает JRuby на Java 6.

В JRuby 1.6 JVM не может оптимизировать код поиска сложных методов в JRuby

На Java 7 мы действительно можем сказать JVM: «Вот как вы смотрите на этот метод. Иди и найди его и свяжи с конкретным звонком. Мы сделаем логику поиска метода. И вот как мы хотим, чтобы вы назвали это. Вот как мы хотим, чтобы вы организовали параметры, вот любая логика, которая должна присутствовать до и после, вот как вы знаете, является ли этот метод правильным для последующего вызова, вот как вы защищаетесь от того, что это другой тип, другой класс, который находится в этот момент. Поскольку мы можем сообщить JVM всю эту информацию, ее гораздо проще оптимизировать. На самом деле он может видеть весь путь от вызова «foo» до целевого метода и понимает всю логику между ними. Это было то, чего мы просто не могли сделать в предыдущих версиях JVM.

В JRuby 1.7 JVM может встроить и оптимизировать динамический вызов

Сама JVM довольно динамична, потому что почти все является объектом, и все они являются виртуальными вызовами. Он должен делать много динамического языка внутри, даже если он статически типизирован на уровне языка Java. Когда дело доходит до фазы связывания в Java 6 JVM, на самом деле есть четыре или пять способов, которыми он знает, как это сделать. Это либо статический вызов, либо виртуальный вызов, либо интерфейсный вызов и т. Д., И он уже жестко запрограммирован в оптимизаторе, чтобы знать, как это сделать как можно быстрее. InvokeDynamic дает нам новый способ связать вызов с целевым методом в терминах, которые он может понимать и оптимизировать, как и все остальные протоколы вызовов.

JRuby 1.7, которая сейчас является главной веткой, — это то место, где выполняется вся работа InvokeDynamic. Вы можете поиграть с ним прямо сейчас — производительность уже выглядит великолепно, хотя у нас еще много работы.

Что дальше?

Q: Я где-то читал, что выходит новый компилятор JRuby, называемый «IR Compiler» — это правильно?

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

Q: Так что будет дополнительный шаг в этом процессе; Вам нужно сначала скомпилировать этот новый набор команд, а затем перевести его обратно в байт-код Java?

Да, точно. Это подошло бы там, где у нас сейчас ходит AST, переводчик AST. Вместо того, чтобы идти прямо в интерпретатор AST, мы могли бы передать код нашему IR-компилятору и оптимизатору, а затем позволить этому некоторое время интерпретировать. И оттуда мы превратили бы IR в байт-код JVM, и в идеале байт-код, который из него получился, был бы как бы «предварительно оптимизирован» и не имел ничего общего.

Q: Какое будущее у JRuby? Что дальше?

Ну, мы продолжаем работать над улучшением производительности JRuby. За последние пару месяцев мы проделали большую работу, чтобы действительно дополнить возможности Ruby 1.9. Мы снова начнем обращать внимание на производительность: IR-компилятор, работа invokeDynamic, все эти вещи должны начать приносить серьезные дивиденды как часть JRuby 1.7 и выше.

Благодарность!

Q: Вау — увлекательно! Спасибо, что объяснили мне все это!

Большое спасибо — приятно пообщаться с вами …