тут больше вопрос с тем как это обозвать =)

interpreter -> GraalVM: eco -> GraalVM: full

или

interpreter ->   -> GraalVM: eco -> full

интерфейс и описание
https://github.com/openjdk/jdk14/blob/master/src/hotspot/share/compiler/tieredThresholdPolicy.hpp

возможные переходы между уровнями
https://github.com/openjdk/jdk14/blob/master/src/hotspot/share/compiler/tieredThresholdPolicy.cpp#L832-L868


вообще обсуждение было, там и ввели доп опцию для ступенчатой high-only-quick-internal
https://bugs.openjdk.java.net/browse/JDK-8227003

// Some compilation levels are not valid depending on a compilation mode:
  // a) quick_only - levels 2,3,4 are invalid; levels -1,0,1 are valid;
  // b) high_only - levels 1,2,3 are invalid; levels -1,0,4 are valid;
  // c) high_only_quick_internal - levels 2,3 are invalid; levels -1,0,1,4 are valid.
  // The invalid levels are actually sequential so a single comparison is sufficient.
  // Down here we already have (level > TieredStopAtLevel), which also implies that
  // (TieredStopAtLevel < Highest Possible Level), so we need to return a level that is:
  // a) a max level that is strictly less than the highest for a given compilation mode
  // b) less or equal to TieredStopAtLevel

дальше там для этого уровня вот такой красивый код в момент выбора имеется

} else if (CompilationModeFlag::high_only_quick_internal()) {
    if (force_comp_at_level_simple(method)) {
      return CompLevel_simple;
    } else {
      return CompLevel_full_optimization;
    }
  }

….

bool TieredThresholdPolicy::force_comp_at_level_simple(const methodHandle& method) {
  if (CompilationModeFlag::quick_internal()) {
#if INCLUDE_JVMCI
    if (UseJVMCICompiler) {
      AbstractCompiler* comp = CompileBroker::compiler(CompLevel_full_optimization);
      if (comp != NULL && comp->is_jvmci() && ((JVMCICompiler*) comp)->force_comp_at_level_simple(method)) {
        return true;
      }
    }
#endif
  }
  return false;
}

отдают подключаемому компилятору решать нужно метод по быстрому компилить или нет

это пример как оставить пользовательский код только c2/graal
но для самого graal разрешить c1

костыльненько на if но работает =)

@xhumanoid прикольно. Спасибо! Заюзаю.

graalvm compiler работает через jvmci

c1/c2 через вот это да https://github.com/openjdk/jdk14/tree/master/src/hotspot/share/compiler

короче, я бы не назвал это заменить с1 )

я бы назвал это применить tiered compilation в GraalVM compiler

но видимо тут наши мнения расходятся

Ну они сейчас от c1 зависят так как libgraal не был готов и graal eco тоже только в процессе

Как только любое из этого стартует необходимость в c1 снижается

Когда стартуют оба пункта, то с1 уже вообще не нужен

И остаётся tired в самом graal

Применить tiered в graal и выключить и c1 и c2 без потерь :)

Я знаю, поэтому показал сразу на код и пример введение high-only-quick-internal для случаев чтобы твой код компилировало только graal, но самому граалю возможность использовать c1 оставить :)

В общем чтобы подвести черту:

В коде во многих местах размазано c1/c2
В момент старта на компиляторы выделяется структура на 2 элемента (abstract compiler)

compiler[0] = null / c1
compiler[1] = null / c2 / jvmci

Дальше уже вагон плясок вокруг этого (каждому свой пул потоков, своя очередь и тд)

Полностью без с1 в граале сейчас нельзя, так как слишком медленно стартует

После libgraal и добавления профиля eco и возможности отключения c1/c2 будет ли идти вопрос о замене или выполнении тех же функций можно спорить долго

Но получим

compiler[0] = null
compiler[1] = jvmci

И ci умеет и быстро код выдавать и быстрый :)

блин, libgraal уже с лета же есть

это миллион лет назад

Только в graalvm :)

Мы же обсуждаем общий jdk :)

а, понятно. я просто технологию в общем и целом

Метрополис ведь тянет и из опенждк, и грааль подмерживает и сами вроде что-то думают

Грааль постоянно обратно в опенждк вливает изменения и даёт фидбек как jvmci работает и куда его развивать :)

Но та же graalvm только недавно стала 11 уметь, а так была на java 8 с патчами для jvmci