[Из песочницы] Инициализация и работа интерпретатора байткода в JVM HotSpot под x8628.09.2019 19:34

Эти параметры в дальнейшем нужны для генерации кода шаблонов интерпретатора

II. Инициализация код кэша

Для того, чтобы сгенерить код шаблонов интерпретатора, необходимо сперва выделить под это дело память. Резервация памяти под код кэш реализована в функции с одноименным названием CodeCache: initialize (). Как можно видеть из следущего участка кода данной функции

 CodeCacheExpansionSize = align_up(CodeCacheExpansionSize, os::vm_page_size());

  if (SegmentedCodeCache) {
    // Use multiple code heaps
    initialize_heaps();
  } else {
    // Use a single code heap
    FLAG_SET_ERGO(uintx, NonNMethodCodeHeapSize, 0);
    FLAG_SET_ERGO(uintx, ProfiledCodeHeapSize, 0);
    FLAG_SET_ERGO(uintx, NonProfiledCodeHeapSize, 0);
    ReservedCodeSpace rs = reserve_heap_memory(ReservedCodeCacheSize);
    add_heap(rs, "CodeCache", CodeBlobType::All);
  } 

код кэш контролируется опциями -XX:ReservedCodeCacheSize, -XX:SegmentedCodeCache, -XX:CodeCacheExpansionSize, -XX:NonNMethodCodeHeapSize, -XX:ProfiledCodeHeapSize, -XX:NonProfiledCodeHeapSize. Краткое описание данных опций можно посмотреть по ссылкам на которые они ведут. Помимо коммандной строки, значения некоторых из этих опций подстраивается эргономикой, например, если используется значение SegmentedCodeCache по умолчанию (выключен), то при размере кода >= 240Mb, SegmentedCodeCache будет включен в CompilerConfig: set_tiered_flags.

После выполнения проверок резервируется область размером в ReservedCodeCacheSize байт. В случае, если SegmentedCodeCache оказалась выставленной, то данная область разбивается на части: JIT-скомпилированные методы, стаб рутины, и т.д.

III. Инициализация шаблонов интерпретатора

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

Рассмотрим каждый из этих этапов по отдельности:

  { CodeletMark cm(_masm, "slow signature handler");
    AbstractInterpreter::_slow_signature_handler = generate_slow_signature_handler();
  }

signature handler используется для подготовки аргументов для вызовов нативных методов. В данном случае генерится обощенный хэндлер, если, например у нативного метода больше 13 аргументов (В дебаггере не проверял, но судя по коду должны быть так)

 { CodeletMark cm(_masm, "error exits");
    _unimplemented_bytecode    = generate_error_exit("unimplemented bytecode");
    _illegal_bytecode_sequence = generate_error_exit("illegal bytecode sequence - method not verified");
  }

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

После вызова процедур необходимо восстановить данные стек фрейма, который был до вызова процедуры из которой делается return.

Используется при вызовах рантайма из интерепретатора.

  // Bytecodes
  set_entry_points_for_all_bytes();

  // installation of code in other places in the runtime
  // (ExcutableCodeManager calls not needed to copy the entries)
  set_safepoints_for_all_bytes();

Для выполнения инструкции спецификация VM требует чтобы операнды находились в Operand Stack, но это не запрещает HotSpot кэшировать их в регистре. Для определения текущего состояния вершины стека используется перечисление

enum TosState {         // describes the tos cache contents
  btos = 0,             // byte, bool tos cached
  ztos = 1,             // byte, bool tos cached
  ctos = 2,             // char tos cached
  stos = 3,             // short tos cached
  itos = 4,             // int tos cached
  ltos = 5,             // long tos cached
  ftos = 6,             // float tos cached
  dtos = 7,             // double tos cached
  atos = 8,             // object cached
  vtos = 9,             // tos not cached
  number_of_states,
  ilgl                  // illegal state: should not occur
};

Каждая инструкция определяет входные и выходные состояния TosState вершины стека, и генерация шаблонов происходит в зависимости от этого состояния. Данные шаблоны инициализируются в удобочитаемой таблице шаблонов. Фрагмент этой таблицы выглядит следующим образом:

 //                                    interpr. templates
  // Java spec bytecodes                ubcp|disp|clvm|iswd  in    out   generator             argument
  def(Bytecodes::_nop                 , ____|____|____|____, vtos, vtos, nop                 ,  _           );
  def(Bytecodes::_aconst_null         , ____|____|____|____, vtos, atos, aconst_null         ,  _           );
  def(Bytecodes::_iconst_m1           , ____|____|____|____, vtos, itos, iconst              , -1           );
  def(Bytecodes::_iconst_0            , ____|____|____|____, vtos, itos, iconst              ,  0           );
  def(Bytecodes::_iconst_1            , ____|____|____|____, vtos, itos, iconst              ,  1           );
  def(Bytecodes::_iconst_2            , ____|____|____|____, vtos, itos, iconst              ,  2           );
  def(Bytecodes::_iconst_3            , ____|____|____|____, vtos, itos, iconst              ,  3           );
  def(Bytecodes::_iconst_4            , ____|____|____|____, vtos, itos, iconst              ,  4           );
  def(Bytecodes::_iconst_5            , ____|____|____|____, vtos, itos, iconst              ,  5           );
  def(Bytecodes::_lconst_0            , ____|____|____|____, vtos, ltos, lconst              ,  0           );
  def(Bytecodes::_lconst_1            , ____|____|____|____, vtos, ltos, lconst              ,  1           );
  def(Bytecodes::_fconst_0            , ____|____|____|____, vtos, ftos, fconst              ,  0           );
  def(Bytecodes::_fconst_1            , ____|____|____|____, vtos, ftos, fconst              ,  1           );
  def(Bytecodes::_fconst_2            , ____|____|____|____, vtos, ftos, fconst              ,  2           );
  def(Bytecodes::_dconst_0            , ____|____|____|____, vtos, dtos, dconst              ,  0           );
  def(Bytecodes::_dconst_1            , ____|____|____|____, vtos, dtos, dconst              ,  1           );
  def(Bytecodes::_bipush              , ubcp|____|____|____, vtos, itos, bipush              ,  _           );
  def(Bytecodes::_sipush              , ubcp|____|____|____, vtos, itos, sipush              ,  _           );

Нам будут особенно интересны столбцы in, out и generator.

in — состояние вершины стека на момент начала исполнения инструкции
out — состояния вершины стека на момент завершения исполнения инструкции
generator — генератор шаблона машинного кода инструкции

Общий вид шаблона для всех байткодов можно описать в виде:

1. Если для инструкции не выставлен dispatch bit, то выполняется пролог инструкции (no-op на x86)

   
   

2. Используя generator, генерится машинный код

   
   

3. Если для инструкции не выставлен dispatch bit, то выполняется переход к следующей по порядку инструкции в зависимости от out состояния вершины стека, которое будет являтся in для следующей инструкции

   
   

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

В HotSpot за это отвечает следущий, относительно стремный кусок кода:

void TemplateInterpreterGenerator::set_entry_points(Bytecodes::Code code) {
  CodeletMark cm(_masm, Bytecodes::name(code), code);
  // initialize entry points
  assert(_unimplemented_bytecode    != NULL, "should have been generated before");
  assert(_illegal_bytecode_sequence != NULL, "should have been generated before");
  address bep = _illegal_bytecode_sequence;
  address zep = _illegal_bytecode_sequence;
  address cep = _illegal_bytecode_sequence;
  address sep = _illegal_bytecode_sequence;
  address aep = _illegal_bytecode_sequence;
  address iep = _illegal_bytecode_sequence;
  address lep = _illegal_bytecode_sequence;
  address fep = _illegal_bytecode_sequence;
  address dep = _illegal_bytecode_sequence;
  address vep = _unimplemented_bytecode;
  address wep = _unimplemented_bytecode;
  // code for short & wide version of bytecode
  if (Bytecodes::is_defined(code)) {
    Template* t = TemplateTable::template_for(code);
    assert(t->is_valid(), "just checking");
    set_short_entry_points(t, bep, cep, sep, aep, iep, lep, fep, dep, vep);
  }
  if (Bytecodes::wide_is_defined(code)) {
    Template* t = TemplateTable::template_for_wide(code);
    assert(t->is_valid(), "just checking");
    set_wide_entry_point(t, wep);
  }
  // set entry points
  EntryPoint entry(bep, zep, cep, sep, aep, iep, lep, fep, dep, vep);
  Interpreter::_normal_table.set_entry(code, entry);
  Interpreter::_wentry_point[code] = wep;
}

//...
void TemplateInterpreterGenerator::set_short_entry_points(Template* t, address& bep, address& cep, address& sep, address& aep, address& iep, address& lep, address& fep, address& dep, address& vep) {
  assert(t->is_valid(), "template must exist");
  switch (t->tos_in()) {
    case btos:
    case ztos:
    case ctos:
    case stos:
      ShouldNotReachHere();  // btos/ctos/stos should use itos.
      break;
    case atos: vep = __ pc(); __ pop(atos); aep = __ pc(); generate_and_dispatch(t); break;
    case itos: vep = __ pc(); __ pop(itos); iep = __ pc(); generate_and_dispatch(t); break;
    case ltos: vep = __ pc(); __ pop(ltos); lep = __ pc(); generate_and_dispatch(t); break;
    case ftos: vep = __ pc(); __ pop(ftos); fep = __ pc(); generate_and_dispatch(t); break;
    case dtos: vep = __ pc(); __ pop(dtos); dep = __ pc(); generate_and_dispatch(t); break;
    case vtos: set_vtos_entry_points(t, bep, cep, sep, aep, iep, lep, fep, dep, vep);     break;
    default  : ShouldNotReachHere();                                                 break;
  }
}

//...

void TemplateInterpreterGenerator::generate_and_dispatch(Template* t, TosState tos_out) {
  if (PrintBytecodeHistogram)                                    histogram_bytecode(t);
#ifndef PRODUCT
  // debugging code
  if (CountBytecodes || TraceBytecodes || StopInterpreterAt > 0) count_bytecode();
  if (PrintBytecodePairHistogram)                                histogram_bytecode_pair(t);
  if (TraceBytecodes)                                            trace_bytecode(t);
  if (StopInterpreterAt > 0)                                     stop_interpreter_at();
  __ verify_FPU(1, t->tos_in());
#endif // !PRODUCT
  int step = 0;
  if (!t->does_dispatch()) {
    step = t->is_wide() ? Bytecodes::wide_length_for(t->bytecode()) : Bytecodes::length_for(t->bytecode());
    if (tos_out == ilgl) tos_out = t->tos_out();
    // compute bytecode size
    assert(step > 0, "just checkin'");
    // setup stuff for dispatching next bytecode
    if (ProfileInterpreter && VerifyDataPointer
        && MethodData::bytecode_has_profile(t->bytecode())) {
      __ verify_method_data_pointer();
    }
    __ dispatch_prolog(tos_out, step);
  }
  // generate template
  t->generate(_masm);
  // advance
  if (t->does_dispatch()) {
#ifdef ASSERT
    // make sure execution doesn't go beyond this point if code is broken
    __ should_not_reach_here();
#endif // ASSERT
  } else {
    // dispatch to next bytecode
    __ dispatch_epilog(tos_out, step);
  }
}

Как только данная кодогенерация завершена, интепретатор можно считать полностью проинициализированным. После интерпретатора выполняется еще много инициализаций различных подсистем JVM. Для некоторых из них требуется вызывать Java-код из кода виртуальной машины. Это реализовано с помощью стандартного механизма JavaCalls. После того как инициализация JVM полностью завершена, этот механизм используется для вызова метода main.

Пример

Для того, чтобы представлять как это все работает на практике, рассмотрим следующий относительно простой пример:

public class Sum{
    public static void sum(int a, int b){
        return a + b;
    }
}

public class Main {
    public static void main(String args[]){
        Sum.sum(2, 3);
    }
}

и попытаемся понять что происходит при вызове метода Sum.sum(II).

Скомпилируем эти 2 класса javac -c *.java и убедимся в том, что компилятор не сделал никаких оптимизаций.
Байткод Sum.sum:

    descriptor: (II)I
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=2, args_size=2
         0: iload_0
         1: iload_1
         2: iadd
         3: ireturn
      LineNumberTable:
        line 3: 0

Байткод Main.main

    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: iconst_2
         1: iconst_3
         2: invokestatic  #2                  // Method Sum.sum:(II)I
         5: pop
         6: return
      LineNumberTable:
        line 13: 0
        line 14: 6

Байткод ровно такой, какой нам нужен и первое с чего придется начать — это с анализа вызова статического метода.

Генератор шаблона invokestatic'а для x86 находится в архитектурно-зависимой секции кода HotSpot и представлен в виде

void TemplateTable::invokestatic(int byte_no) {
  transition(vtos, vtos);
  assert(byte_no == f1_byte, "use this argument");
  prepare_invoke(byte_no, rbx);  // get f1 Method*
  // do the call
  __ profile_call(rax);
  __ profile_arguments_type(rax, rbx, rbcp, false);
  __ jump_from_interpreted(rbx, rax);
}

byte_no == f1_byte — это секция ConstantPoolCache, относящаяся к статическим методам, rbx — регистр, в котором будет храниться указатель Method *. В остальном все в принципе понятно: Подготовка вызова, профайлинг, переход на точку входа метода (method_entry при генерации шаблонов интерпретатора).

Рассмотрим подронее prepare_invoke. Как известно, следом за байткодом инструкции invokestatic идет индекс в ConstantPool на Constant_Methodref_Info. В случае HotSpot это не совсем так. Следущие 2 байта указывают на индекс в т.н. ConstantPoolCache. ConstantPoolCache это структура данных в которой хранится информация, нужная для интерпретатора (например, было ли зарезолвено ConstantPoolCacheEntry по данному индексу, реализуя таким образом ленивость загрузки классов). После того как это ConstantPoolCacheEntry зарезолвено, в него записывается номер байткода (изначально там был 0) и этот номер используется при дальнейшем определении зарезолвено/не зарезолвено. Несмотря на то, что при загрузке класса индексы изначально указывают в ConstantPool, при линковке класса они будут перезаписаны на ConstantPoolCache индексы в нативном байт ордере (на x86 Little Endian).

Итак, первое, что HotSpot пытается сделать в prepare_invoke — это достать индекс на ConstantPoolCache. После того, как индекс получен, делается проверка на зарезолвенность ConstantPoolCacheEntry по данному индексу

  __ get_cache_and_index_and_bytecode_at_bcp(Rcache, index, temp, byte_no, 1, index_size);
  __ cmpl(temp, code);  // have we resolved this bytecode?
  __ jcc(Assembler::equal, resolved);

  // resolve first time through
  address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
  __ movl(temp, code);
  __ call_VM(noreg, entry, temp);
  // Update registers with resolved info
  __ get_cache_and_index_at_bcp(Rcache, index, 1, index_size);
  __ bind(resolved);

Если нет, значит нужно вызывать InterpreterRuntime::resolve_from_cache.

В данной функции выполняется загрузка класса receiver’a вызываемого статического метода, если на данный момент класс еще не был загружен. После загрузки выполняется инициализация (линковка, валидация, перезаписывание байткода, создание ConstantPoolCache и вызов , если такой метод присутствует в байткоде). Не ленивая инициализация может выполняться и сразу после define class, если выставлен флаг EagerInitialization (флаг девелоперский, поэтому из коммандной строки не доступен, но кто нам запретит у себя его поменять на продакшн :)). Вообще загрузка классов в HotSpot в общем (и CDS в частности) имеет относительно не тривиальную реализацию.

После того, как класс инициализирован и нужный метод в классе найден, инициализируется соответветствующее ConstantPoolCacheEntry этими байткодом и методом. После этого интерпретатор загружает указатель Method * в rbx, достает адрес возврата, делает профайлинг и переходит на точку входа вызовав метода.

Исследуем теперь точку входа при вызове Sum.sum(2, 3). Для этого нам потребуется следующий gdb-script sum.gdb:

#Путь к исполняемому файлу java
file /home/dmitrii/jdk12/build/linux-x86_64-server-fastdebug/images/jdk/bin/java

#Говорим gdb не останавливаться на SEGV'ах
#таких, как этот https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/hotspot/cpu/x86/vm_version_x86.cpp#l361
handle SIGSEGV nostop noprint

#Символы на данный момент еще не загружены
set breakpoint pending on

#Чтобы быстро проскипать статические методы,
#не относящиеся к эксперименту
set pagination off

#Ставим брейк сразу перед вызовом метода main
b PostJVMInit
commands
    #Буффер для сигнатур методов,
    #иначе упадем в корку
    set $buffer = malloc(1000)

    #Точка входа в метод.
    #jmp по этому адресу делается в генерируемом
    #шаблоне invokestatic
    b *AbstractInterpreter::_entry_table[0] thread 2
    commands
        #В соответсвии с кодом шаблона invokestatic,
        #указатель Method* хранится в rbx
        set $mthd = (Method *) $rbx
        #Получаем сигнатуру метода в $buffer
        call $mthd->name_and_sig_as_C_string($buffer, 1000)
        if strcmp()($buffer, "Sum.sum(II)I") == 0
            #Брейкпоинт на iload_0, вершина стека не закеширована
            b *TemplateInterpreter::_normal_table._table[vtos][26] thread 2
            #Брейкпоинт на iload_1, вершина стека - int, закеширована
            #после выполнения iload_0
            b *TemplateInterpreter::_normal_table._table[itos][27] thread 2
            #Брейкпоинт на инструкции iadd
            b *TemplateInterpreter::_normal_table._table[itos][96] thread 2
        end
        c
    end
    c
end

r -cp . Main

Запустив данный скрипт gdb -x sum.gdb, останавливаемся на точке входа в метод Sum.sum

$453 = 0x7ffff7fdcdd0 "Sum.sum(II)I"

Если открыть layout asm, то мы увидим код, сгенеренный методом generate_normal_entry. В данном шаблоне делается создание стек-фрейма, проверка StackOverflow, stack-banging и далее делается dispatch на первую инструкцию iload_0 при незакешированной вершине стека. В этом случае код интерпретатора имеет вид:

0x7fffd828fa1f  mov    eax,DWORD PTR [r14] ;собственно, iload_0                                                                                                                                    0x7fffd828fa22  movzx  ebx,BYTE PTR [r13+0x1] ;загружаем следующий байткод                                                                                                                                     0x7fffd828fa27  inc    r13 ;инкремент bcp (byte code pointer)                                                                                                                    0x7fffd828fa2a  movabs r10,0x7ffff717e8a0 ;загрузка DispatchTable                                                                                                                                 0x7fffd828fa34  jmp    QWORD PTR [r10+rbx*8] ;jump в зависимости от вершины стека

После этого вершина стека оказалась закешированной в rax, а значит интерпретатор переходит в следующий шаблон

0x7fffd828fabe  push   rax ;кладем кешированную вершину на стек                                                                                                                       
;далее все тоже самое, что и в предыдущем примере
0x7fffd828fabf  mov    eax,DWORD PTR [r14-0x8]                                                                                                                                                               0x7fffd828fac3  movzx  ebx,BYTE PTR [r13+0x1]                                                                                                                                                                0x7fffd828fac8  inc    r13                                                                                                                                                                                   0x7fffd828facb  movabs r10,0x7ffff717e8a0                                                                                                                                                                     0x7fffd828fad5  jmp    QWORD PTR [r10+rbx*8]    

Ну, а теперь и сама инструкция iadd:

0x7fffd8292ba7  mov    edx,DWORD PTR [rsp] ;загружаем то, что ранее запушили в iload_1                                                                                                                                    0x7fffd8292baa  add    rsp,0x8 ;поправляем rsp руками после загрузки                                                                                                                            0x7fffd8292bae  add    eax,edx ;сложение двух интов                                                                                                                      0x7fffd8292bb0  movzx  ebx,BYTE PTR [r13+0x1]                                                                                                                                                                 0x7fffd8292bb5  inc    r13                                                                                                                                                                                    0x7fffd8292bb8  movabs r10,0x7ffff717e8a0                                                                                                                                                                     0x7fffd8292bc2  jmp    QWORD PTR [r10+rbx*8] 

Если посмотреть в gdb на eax и edx сразу перед выполнением сложения, то можно заметить

(gdb) p $eax
$457 = 3
(gdb) p $edx
$458 = 2

А это и есть те самые операнды, которые мы передали функции Sum.sum.

© Habrahabr.ru