даже это не оязано быть правдой. Представь себе что у тебя массив из 3х интов. Каждый из них используется в каком-то месте и не меняется в массиве. Потенциально мы можем выкинуть массив и просто прокидывать эти инты через стэк

Это сложная оптимизация. Простая оптимизация — выкинуть обёртку в виде InternalRow и работать с самим массивом, пользуясь тем, что в ассемблере нет типов

тогда на стэке будет указатель на массив в хипе, конечно

там обращение идет через медоты с несколькими параметрами. в самих методах кроде доступа есть еще проверки. нельзя просто так его выкинуть компилятором этот кусок кода и заменить на доступ база+смещение. или какая другая идея в этом?

можно, если звёзды сошлись

То есть если у тебя на самом деле всегда одно и то е передаётся кроме индекса массива — то одно и то всё что внутри моно заинлайнить в безумловные переходы

Например посмотри на тот код https://gist.github.com/asm0dey/5c0fa4c985ab999b383d16257b515100#file-scratch-java-L57

Если присмотреться — окажется что InternalRow вообще не используется!

localtablescan_row_0.getInt(0) - вот он вызов

Это да, я имею в виду что InternalRow прокидывается дальше, но не используется. А getInt(0) — как раз оптимизируемая операция потому что там всегда будет int, а не String, например

а ещё примечательно что конкретно в этом случае можно просто взять и переложить данные из InternalRow в mutable state :)

точнее не так. internalrow.get(0) . map . write (0)

К вопросу об оптимальности сгенерированного кода

оно прокидывается только туда, где может понадобиться. в map оно уже не нужно. поэтому там его нет. оно может понадобится только в deserializetoobject и поэтому туда и прокинули. может компилятор и сможет оптимизировать getInt(0), но это не выглядит простой задачей. массив каждой строки в разных местах ведь. и ему еще надо понять, что функции проверки по индексу( который в данном случае 0)  иденпотенты.

Конечно, но и потимизации у тебя разные на каждом пути. В рамках конкретного пайплайна путь исполнения может быть и один (как тут)

А насчёт непростой задачи — я бы даже сказал что она очень сложная и поэтому это многолетняя работа ребят из Oracle Labs, которая вот сейчас вылилась в грааль JIT

а как он поймет, что функции проверки можно отбрросить?   private void assertIndexIsValid(int index) {
   assert index >= 0 : "index (" + index + ") should >= 0";
   assert index < numFields : "index (" + index + ") should < " + numFields;
 }

Там же счётчик. Как у тебя не проверяются на самом деле каждый раз границы массива. Считаем сколько раз мы попали в границы, если попали, например 1000 — компилируем этот буть в машинный коди ходим по нему. Как только словили ошибку доступа — деоптимизируем всё нахер, скатываемся в этом месте в интерпретацию (C0 то есть) и иди по интерпретируемому пути с проверками границ. Как только в границы не попали — кидаем исключение

То есть это буквально то, как работает tiered compilation в JVM

там дочтуп через unsafe - UNSAFE.getInt. не уверен, что он поймет, что папали за границу. поэтому они там и сделали кастомную проверку руками на границу достпупа, которую выкинуть значит нельзя