Проверка использования стека во время компиляции
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
7 ответов
Код ядра Linux работает на стопке 4K на x86. Следовательно они заботятся. То, что они используют, чтобы проверить, что, сценарий жемчуга, который они записали, который можно найти как scripts/checkstack.pl в недавнем ядре tarball (2.6.25 имеет его). Это работает на выводе objdump, документация использования находится в первоначальном комментарии.
я думаю, что уже использовал его для двоичных файлов пространства пользователя давным-давно, и если Вы знаете немного программирования жемчуга, легко зафиксировать это, если это повреждается.
Так или иначе, то, что это в основном делает, должно автоматически посмотреть на вывод GCC. И то, что хакеры ядра записали такой инструмент, означает, что нет никакого статического способа сделать это с GCC (или возможно что это было добавлено совсем недавно, но я сомневаюсь так).
Btw, с objdump из mingw проекта и ActivePerl, или с Cygwin, необходимо быть в состоянии сделать это также в Windows и также в двоичных файлах, полученных с другими компиляторами.
StackAnlyser кажется examinate самим исполняемым кодом плюс некоторая информация об отладке. То, что описано этот ответ , то, что я ищу, стек анализатор похож на излишество мне.
Что-то подобное тому, что существует для ADA, было бы прекрасно. Посмотрите на эту страницу руководства из руководства комара:
22.2 Статических Анализа Использования стека
единица А, скомпилированная с - fstack-использование генерирует дополнительный файл, который определяет максимальную сумму используемого стека на основе на функцию. Файл имеет то же базовое имя как файл целевого объекта с .su расширением. Каждая строка этого файла составлена из трех полей:
* The name of the function.
* A number of bytes.
* One or more qualifiers: static, dynamic, bounded.
второе поле соответствует размеру известной части функционального кадра.
статичный спецификатор означает, что функциональный формат кадра чисто статичен. Это обычно означает, что все локальные переменные имеют статический размер. В этом случае второе поле является надежной мерой функционального использования стека.
динамичный спецификатор означает, что функциональный формат кадра не статичен. Это происходит главным образом, когда некоторые локальные переменные имеют динамический размер. Когда этот спецификатор кажется одним, второе поле не является надежной мерой функционального анализа стека. Когда это квалифицировано с ограниченным, это означает, что второе поле является надежным максимумом функционального использования стека.
Я не вижу, почему статический анализ кода не мог дать достаточно хорошему числу для этого.
Это тривиально для нахождения всех локальных переменных в любой заданной функции, и размер для каждой переменной может быть найден любым через стандарт C (для созданного в типах) или путем вычисления его (для составных типов как структуры и объединения).
Несомненно, ответ, как могут гарантировать, не будет на 100% точен, так как компилятор может сделать различные виды оптимизации как дополнение, поместив переменные в регистры или полностью удалить ненужные переменные. Но любой ответ, который это дает, должен быть хорошей оценкой, по крайней мере.
я сделал быстрый поиск Google и нашел StackAnalyzer, но мое предположение - то, что другие статические инструменты анализа кода имеют подобные возможности.
, Если бы Вы хотите 100%-е точное число, тогда необходимо было бы посмотреть на вывод из компилятора или проверить его во время времени выполнения (как Ralph, предложенный в его ответ )
Только компилятор действительно знал бы, так как это - парень, который соединяет весь Ваш материал. Необходимо было бы посмотреть на сгенерированный блок и видеть, сколько пространства резервируется в преамбуле, но это действительно не составляет вещи как alloca, которые делают их вещь во времени выполнения.
Принятие Вас находится на встроенной платформе, Вы могли бы найти, что Ваш набор инструментальных средств делает попытку этого. Хорошие коммерческие встроенные компиляторы (как, например, компилятор Arm/Keil) часто представляют отчеты использования стека.
, Конечно, прерывания и рекурсия обычно немного вне их, но она дает Вам общее представление, если кто-то фиксировал некоторый ужасный провал со много буфером мегабайта на стеке где-нибудь.
Не точно "время компиляции", но я сделал бы это как шаг постсборки:
- позволяют компоновщику создать файл карты для Вас
- для каждой функции в файле карты, читает соответствующую часть исполняемого файла и анализируют пролог функции.
Это подобно тому, что StackAnalyzer делает, но намного более простой. Я думаю, анализируя исполняемый файл, или дизассемблирование является самым легким способом, которым можно добраться до выхода компилятора. В то время как компилятор знает те вещи внутренне, я боюсь, что Вы не будете в состоянии получить его от него (Вы могли бы попросить, чтобы поставщик компилятора реализовал функциональность, или при использовании компилятора с открытым исходным кодом, Вы могли сделать это сами или позволить кому-то сделать это для Вас).
Для реализации этого Вы должны:
- быть в состоянии проанализировать файл
- карты понимают, что формат исполняемого файла
- знает то, на что пролог функции может быть похожим и быть в состоянии "декодировать" его
, Насколько легкий или трудный это было бы, зависит от Вашей целевой платформы. (Встроенный? Какая архитектура ЦП? Какой компилятор?)
Все это определенно может быть сделано в x86/Win32, но если Вы никогда не делали ничего как это и должны создать все это из царапины, он может взять за несколько дней до того, как Вы будете сделаны и будете иметь что-то работа.
Не в целом. Проблема остановки в теоретической информатике предполагает, что Вы не можете даже предсказать, останавливается ли общая программа на данном входе. Вычисление стека, используемого для прогона программы в целом, было бы еще более сложным. Так: нет. Возможно, в особых случаях.
Скажем, у Вас есть рекурсивная функция, уровень рекурсии которой зависит от входа, который может иметь произвольную длину, и Вы являетесь уже неудачливыми.