Спасибо за статью. Мне кажеться, что многие разработчики недооценивают важность рекомендация №5. Я бы еще рекомендовал быть готовым выслушать идеи автора кода перед тем как разносить в пух и прах его код. Очень часто бывает, что автор предусмотрел случаи, про которые ревьювер не подумал.
Can we please get rid of...
для вида вежливости добавляя «please»
Я всегда воспринимал эту фразу как «Господи, ну давайте уже избавимся от ...». Т.е. «please» в данном случае скорее выражает раздражение, чем вежливую просьбу.
Если я Хром запущу, который сейчас у меня по счётчику отработал 30 часов — думаете он трассу сможет куда-нибудь записать?
rr, например, как раз и создавался для записи реального приложения — Mozilla Firefox. Записывать им трассу на 30 часов не практично, конечно. Записать 30 минут — час совершенно не проблема. Ограничение здесь даже не дисковое пространство — его-то как раз хватит, а время на перемотку. Вот если допилят снапшоты, то и 30 часов не будет большой проблемой.
TTD, если мне не изменяет память, по дисковым требованиям похож на rr.
Откройте мануал к старому древнему Turbo Debugger'у 2.0 1990го года выпуска — и вы увидите эту фичу в разделе «Controlling Program Execution», подраздел «Back Trace».
Вы сравниваете несравнимые вещи. В этом же мануале написано:
Some restrictions apply. See the section, «The Instructions pane (page 86).»
The execution history only keeps track of instructions that have
been executed with the Trace Into command (Fl) or the Instruction
Trace command (AIt-Fl). It also tracks for Step Over, as long as you
don't encounter one of the commands listed on page 84. As soon
as you use the Run command or execute an interrupt, the
execution history is deleted. (It starts being recorded again as
soon as you go back to tracing.)
Иными словами Trace Back в Turbo Debugger — это банальный undo для выполненных вручную шагов по коду. В случае однопоточной программы реализуется тривиально запоминанием контекста процессора на каждом шаге.
TTD — это полноценная записть состояния процесса для всех его потоков. Если делать такую запись в лоб — получаются жуткие тормоза: меденно (так как эмулируется каждая инструкция) и количество данных зашкаливает. Поэтому хорошие реализации хитрят (что TTD, что rr) — избегая необходимости сохранять более 99% состояния.
Есть существительное «stage» («ступень»), а есть глагол «to stage» («разделять ступени»). Если плясать от второго, то считаются все события разделений и путаницы не возникает.
Для разворота там не хватает места — там только две полосы. Для разворота нужно либо три, либо специальный карман. Иначе не все вписываются с первого раза.
The most obvious is that gccgo uses operating system threads to implement goroutines, and will not use segmented stacks in all configurations. This means that creating a goroutine is as expensive as creating a thread in C.
А, понятно. Тогда я согласен с комментарием mc_dir ниже. Тяжелую часть можно вынести в C, через cgo. Правда это слегка подпортит жизнь тем, кто собирает Go под Windows.
Я сильно сомневаюсь, что поправить PATH достаточно для того, чтобы вызывался proxy-компилятор, но при этом не переставал работать основной компилятор.
Proxy должен вызывать оригинальный компилятор с немодифицированным окружением, само собой. Не две срочки кода, но и не сильно сложно.
Собираем эту информацию для каждого файла и в путь.
При таком может теряться информация о зависимостях между разными вызовами компилятора. Не факт, что оно вам нужно, правда.
Так же сложно определить к какому проекту относится каждый конкретный процесс.
Потенциально возможна проблема с генерируемыми файлами. В случае proxy, система сборки позаботится, что исходный файл не будет удален, пока оно нужен компилятору. В вашем случае — не факт.
Короче, я исхожу из того, что аххилесова пята любых подобных перехватчиков — недостаток контекстной информации о перехваченных операциях (что не дает трактовать их правильно) и изменение поведения перехваченных операций. В вашем случае — временные файлы, удаленные после сборки, повторные вызовы компилятора — будут сбивать анализатор с толку. Основное средство борьбы с обоими проблемами — постараться ничем не отличаться от исходного компилятора.
Тут сложно критиковать по делу, так я не знаю как именно вы перехватываете вызовы компилятора. Наиболее беспролемный вариант, насколько я могу себе представить, — это подсунуть вместо компилятора (PATH поправить, например) proxy, который будет сначала делать свою работу, а потом вызывать исходный компилятор, чтобы собрать все как было. При таком подходе теряется минимум контекста — т.е. однозначно понятно, что именно требует система сборки от компилятора. Для контраста — перехват создания всех процессов компилятора уже работает хуже, так как вылезают проблемы если собираются несколько проектов сразу.
Даже при таком подходе правильная имитация компилятора — еше тот геморрой. Вечно вылезают разные тонкости. Добавление поддержки нового компилятора становится большой проблемой, так как приходится переписывать логику разбора параметров командной строки и т.п. В результате будут поддерживаться не все компилаторы, а два-три наиболее ходовых.
Поддержка произвольных систем сборки — тоже не подарок. Скажем ничего не мешает собрать один и тот же исходник с разными параметрами, причем может оказаться, что их всех собранных вариантов используется только один.
как это сделать лучше
Мне нравится идея сделать так, чтобы все работало само. Если это будет работать в 95% реальных проектов и ладно. Если нет, то я бы ограничил разунмость перехватчика и попытался бы сделать так, чтобы добавление анализатора в проект хотя бы и требовало минимальных усилий, но за счет этого, разработчик мог явно объяснить анализатору, что от того требуется.
1. Три ноги плохо вписываются на центальный бак на Falcon Heavy.
2. Ноги планируется использовать для стабилизации ступени при возврате. Эффект от четырех ног будет больше.
> Одному ли мне кажется, что это смахивает на нарушение того соглашения, которое было подписано Майкрософтом в Брюсселе?
Хотель ругнуться матерно, но сдержался. Это смахивает на традиционный баг браузеров, предлагающих установить себя по-умолчанию. Например Firefox любит таким заниматься. Но, конечно же, удобнее во всем видеть заговор.
А что случилось-то? Может в спортлото написать?
Я всегда воспринимал эту фразу как «Господи, ну давайте уже избавимся от ...». Т.е. «please» в данном случае скорее выражает раздражение, чем вежливую просьбу.
rr, например, как раз и создавался для записи реального приложения — Mozilla Firefox. Записывать им трассу на 30 часов не практично, конечно. Записать 30 минут — час совершенно не проблема. Ограничение здесь даже не дисковое пространство — его-то как раз хватит, а время на перемотку. Вот если допилят снапшоты, то и 30 часов не будет большой проблемой.
TTD, если мне не изменяет память, по дисковым требованиям похож на rr.
Вы сравниваете несравнимые вещи. В этом же мануале написано:
Иными словами Trace Back в Turbo Debugger — это банальный undo для выполненных вручную шагов по коду. В случае однопоточной программы реализуется тривиально запоминанием контекста процессора на каждом шаге.
TTD — это полноценная записть состояния процесса для всех его потоков. Если делать такую запись в лоб — получаются жуткие тормоза: меденно (так как эмулируется каждая инструкция) и количество данных зашкаливает. Поэтому хорошие реализации хитрят (что TTD, что rr) — избегая необходимости сохранять более 99% состояния.
На самом деле, TTD — это технология 10-летней давности. Просто Microsoft решила наконец её выпустить в мир: www.usenix.org/legacy/events/vee06/full_papers/p154-bhansali.pdf.
Да, согласен.
Гвен Шотвелл — женщина:
FAQ также утверждает, что:
Я не в курсе значит ли это, что и переключение между goroutines кооперативное под gccgo или нет.
Кастинг в Go медленный. Кошерный способ оптимизации с этом случае — вынос кастинга за пределы цикла.
Proxy должен вызывать оригинальный компилятор с немодифицированным окружением, само собой. Не две срочки кода, но и не сильно сложно.
При таком может теряться информация о зависимостях между разными вызовами компилятора. Не факт, что оно вам нужно, правда.
Так же сложно определить к какому проекту относится каждый конкретный процесс.
Потенциально возможна проблема с генерируемыми файлами. В случае proxy, система сборки позаботится, что исходный файл не будет удален, пока оно нужен компилятору. В вашем случае — не факт.
Короче, я исхожу из того, что аххилесова пята любых подобных перехватчиков — недостаток контекстной информации о перехваченных операциях (что не дает трактовать их правильно) и изменение поведения перехваченных операций. В вашем случае — временные файлы, удаленные после сборки, повторные вызовы компилятора — будут сбивать анализатор с толку. Основное средство борьбы с обоими проблемами — постараться ничем не отличаться от исходного компилятора.
Даже при таком подходе правильная имитация компилятора — еше тот геморрой. Вечно вылезают разные тонкости. Добавление поддержки нового компилятора становится большой проблемой, так как приходится переписывать логику разбора параметров командной строки и т.п. В результате будут поддерживаться не все компилаторы, а два-три наиболее ходовых.
Поддержка произвольных систем сборки — тоже не подарок. Скажем ничего не мешает собрать один и тот же исходник с разными параметрами, причем может оказаться, что их всех собранных вариантов используется только один.
Мне нравится идея сделать так, чтобы все работало само. Если это будет работать в 95% реальных проектов и ладно. Если нет, то я бы ограничил разунмость перехватчика и попытался бы сделать так, чтобы добавление анализатора в проект хотя бы и требовало минимальных усилий, но за счет этого, разработчик мог явно объяснить анализатору, что от того требуется.
Что-то мне это напоминает: blog.not-a-kernel-guy.com/2012/05/04/1317
1. Три ноги плохо вписываются на центальный бак на Falcon Heavy.
2. Ноги планируется использовать для стабилизации ступени при возврате. Эффект от четырех ног будет больше.
VS 2008 более не поддерживаеется. Для сборки требуется VS 2010.
Хотель ругнуться матерно, но сдержался. Это смахивает на традиционный баг браузеров, предлагающих установить себя по-умолчанию. Например Firefox любит таким заниматься. Но, конечно же, удобнее во всем видеть заговор.