1

Когда привязка привязки невозможна во время компиляции, она выполняется при загрузке/ссылке или времени выполнения, чтобы связать относительные (или, возможно, мы сможем их переадресовывать адреса) адреса с фактическими физическими. Кроме того, ЦП также преобразует эти относительные адреса в логические до привязки для физических адресов.Относительные адреса, сгенерированные компилятором, и способы их представления в байт-коде (предпочтительно java)?

Преобразование из логического в физическое - это известная концепция для меня. Но я смутился об этих относительных адресах (AFAIK, они называли родственников, потому что они переданы/назначены относительно нуля компилятором). Я не уверен, какие относительные адреса используются (в байте-коде), или если они действительно нужны, или они даже идентичны логическим адресам?

+1

Вы сняли вопрос в ногу, представив RELOCATABLE. Это независимая концепция, которая на данный момент выходит за рамки вашего понимания. –

+0

@BruceDavidWilner Насколько я помню. Могут быть два типа привязки адреса. Относительно логического и логического относительно. Иногда иногда относительный адрес и ссылочные термины используются взаимозаменяемо. Вот почему я использовал этот термин. – zgulser

+0

@BruceDavidWilner Но я согласен с вашей точкой зрения. Перемещаемый больше относится к еще неразрешенным адресам (если вы имели ввиду). – zgulser

ответ

1

Вы смешиваете множество концепций. Относительный адрес - это просто адрес, для которого необходим базовый адрес для преобразования в абсолютный адрес. Это преобразование может произойти во многих отношениях. One способ преобразовывает их во время загрузки, но их также можно использовать только вместе с инструкциями CPU, которые по существу поддерживают относительную адресацию, делая математику справа, когда необходимо получить доступ к памяти.

Если операционная система поддерживает виртуальную память, все адреса, используемые в обычном процессе, являются логическими, независимо от того, имеют ли они относительные или абсолютные ссылки. Переход от логических к физическим адресам выходит за рамки приложения и не зависит от какой-либо другой концепции, о которой вы говорите в своем вопросе.

Формат файла класса не работает с точки зрения местоположения памяти.

Если вы хотите применить термины «абсолютный» и «относительный» на этом более высоком уровне, индексы постоянного пула абсолютные, поскольку они не требуют базового индекса для определения фактического индекса. Тем не менее, если вы хотите найти местоположение памяти в загруженном файле, вам нужно не только использовать адрес, к которому был загружен файл класса, но также необходимо проанализировать весь пул констант до нужного элемента, поскольку постоянные пулы разные размеры байтов. По этой причине элементы обычно не просматриваются вообще. Вместо этого весь пул преобразуется в конкретное представление JVM с постоянными размерами элементов за один проход, а позже JVM может искать записи этой таблицы, которая не зависит от местоположения памяти файла класса.

В инструкциях с байтовым кодом используются относительные смещения, которые требуют добавления позиции текущей инструкции для получения абсолютной позиции, но обратите внимание, как это не соответствует понятиям, указанным в вашем вопросе. Абсолютные позиции по-прежнему являются позициями в последовательности команд и, следовательно, относительно местоположения памяти кода при разговоре о адресах. Кроме того, относительные смещения не используются, поскольку «привязка невозможна во время компиляции», результирующие абсолютные позиции известны во время компиляции. Набор инструкций для байтового кода Java определен только для использования относительных смещений для обеспечения более компактного кода. С точки зрения набора инструкций мы могли бы сказать, что он по существу поддерживает относительную адресацию. Как JVM фактически реализует свое исполнение, зависит от JVM.

С you mentioned the JVM’s native code generation, когда JVM создает собственный код, он знает адрес цели кода и может свободно решать использовать относительные или абсолютные адреса, точно так же, как он подходит.

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

+0

Я читал ранее о связи между процессом и его логическими и физическими адресными пространствами. Спасибо за напоминание. В частности, я пытаюсь прочитать файл декодированного класса (gen. Компилятором) и видеть множество чисел, ссылающихся на постоянный пул, массив локальных переменных, байт-код и т. Д. Таким образом, неизбежно, я пытаюсь связать эти числа (относительные смещения, если хотите) с их логическими аналогами, предполагая, что они еще не привязаны компилятором. И, исходя из ваших взглядов выше, и, как говорили другие, это делается JVM. – zgulser

+0

Плюс, я обращался к абсолютным адресам как к физическим адресам и получил вашу мысль сказать «это не вписывается в понятия, названные в вашем вопросе». – zgulser

+0

Непонятно, что вы имеете в виду «еще не связанный компилятором» при обращении к номерам в файле класса. Все они были связаны компилятором, поскольку на самом деле это был компилятор, который придавал им значение.Это становится еще более странным, когда вы говорите, что вы смотрите на * декодированные * файлы классов, так как тогда решение декодера показало вам номер вместо фактического элемента (говорящего, например, о постоянных элементах пула). Файл класса - это [только файл] (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html), который вы можете анализировать, не зная, что с ним будет работать JVM. – Holger

1

Java байт-код работает на гораздо более высоком уровне абстракции, чем собственный машинный код. Нет никакого понятия о адресах памяти вообще - методы упоминаются символически.

Самый простой способ думать о байт-коде Java состоит в том, что он практически 1: 1 с начальной версией языка Java. Компилятор делает некоторые вещи, такие как преобразование локальных переменных в числовые индексы и преобразование потока управления в gotos, но по большей части он очень похож на исходный код.

JVM отвечает за интерпретацию или компиляцию байт-кода в собственный код во время выполнения.

+0

Спасибо. Я получил концепцию абстракции JVM и символических ссылок. Но я пытаюсь получить немного глубже. Прежде всего, каковы именно эти относительные адреса в байтекоде? Например, могут быть приведены в качестве примера постоянные ссылки на пул (# 3, # 20 и т. Д.) Или индексы массива байткода (те, которые указаны в левой части инструкций 0 :, 2: 4 :)? Во-вторых, механизм JVM-выполнения заранее конвертирует байт-код в собственный/машинный код. Являются ли эти nativecode непосредственно исполняемыми или должны быть отфильтрованы MMU, чтобы привязать их к их фактическим физическим адресам? – zgulser

1

Получение адресов памяти объектов на самом деле бессмысленно в Java: поскольку JVM управляет всем этим.

Другими словами: JVM «ставит» объекты, где бы они ни находились; и их можно даже «перемещать»; например, во время сбора мусора.

Другими словами: как программист на Java, вам все равно. И если вам будет интересно; вы ничего не можете с этим поделать.

+0

Да, меня это волнует :). И я не хочу делать лишние вещи. Просто пытаюсь понять, что происходит под капотом. – zgulser

+1

Тогда вам, вероятно, придется очень глубоко погрузиться в детали реализации реализации JVM. – GhostCat

+0

Я заметил :). – zgulser

 Смежные вопросы

  • Нет связанных вопросов^_^