It's been two years since we last checked the code of the LLVM project with PVS-Studio, so let's see if PVS-Studio is still the leader among tools for detecting bugs and security weaknesses. We'll do that by scanning the LLVM 8.0.0 release for new bugs.
Читать полностью »
Время от времени мы возвращаемся к проектам, которые уже проверяли ранее с помощью PVS-Studio и писали про это статьи. Делать это интересно по двум причинам. Во-первых, чтобы понять, насколько лучше стал наш анализатор. Во-вторых, чтобы отследить, обратили ли авторы проекта внимание на нашу статью, а также на отчет об ошибках, который мы им обычно предоставляем. Конечно, ошибки могут быть исправлены и без нашего участия. Но всегда приятно, когда именно наши усилия помогают сделать какой-то проект лучше. Не стал исключением и Roslyn. Предыдущая статья о проверке этого проекта датируется 23 декабря 2015 года. Это довольно давно, учитывая путь, который за это время проделал в своём развитии наш анализатор. Дополнительный интерес лично для нас Roslyn представляет ещё и тем, что на нём базируется ядро C# анализатора PVS-Studio. Таким образом, мы очень заинтересованы в качестве кода этого проекта. Устроим ему повторную проверку и выясним, что же нового и интересного (но будем надеяться, что ничего существенного) там сможет найти PVS-Studio.
Читать полностью »
Это последняя часть моего обзора компилятора Swift. Я покажу, как можно осуществить генерацию LLVM IR из AST и что выдаёт настоящий фронтенд. Если вы не читали предыдущие части, то переходите по ссылкам:
Several years ago I wrote a Pascal compiler. The motivation was simple: as a teenager, I had learnt from my first programming textbooks that a compiler is a very sophisticated thing. This claim eventually became a challenge and required to be tested by experience.
ha.art.pl
First, a simplistic PL/0 compiler came into being, and later an almost fully-functional Pascal compiler for MS-DOS has grown from it. My source of inspiration was the Compiler Construction book by Niklaus Wirth, the inventor of the Pascal language. I don't care if Wirth's views are now considered obsolete and have no direct connections to the IT mainstream, or if the compiler design fashion has changed. It is enough to know that his techniques are still simple, elegant, and — last but not least — bring much fun, since it is more appealing to parse a program source with a handwritten recursive descent parser and generate the machine code, rather than to call yaccs, bisons and all their descendants.
My compiler's fate was not so trivial. It has lived two lives: the first one in my own hands, and the second in the hands of computer antiquarians from Poland.
Читать полностью »
Вторая часть моего рассказа о компиляторе Swift. Мы начнём изучать фронтенд, а точнее те его части, которые отвечают за первоначальный разбор и анализ исходного кода. Читать полностью »
Речь в этой статье пойдёт о небольшой security-фиче, добавленной в GNU ld к релизу 2.30 в декабре 2018 года. На русском языке это улучшение упоминалось на opennet с такой аннотацией:
режим "-z separate-code", повышающий защищённость исполняемых файлов ценой небольшого увеличения размера и потребления памяти
Давайте разберёмся. Чтобы объяснить, о какой проблеме безопасности идёт речь и в чём состоит решение, начнём с общих черт эксплойтов бинарных уязвимостей.
Дефицита технических материалов о Kotlin нет, узнать о корутинах или nullability можно много где. Но остаётся куда менее освещённой другая сторона: а как вообще выглядит процесс разработки языка? Как принимаются решения? Каковы задачи у «самого главного человека»? Остаётся ли у него в жизни время на что-либо ещё?
И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.
Читать полностью »
Во вторник, 5 июня, в петербургском офисе компании Oracle состоится встреча JUG.ru с Артуром Пилипенко, инженером компиляторной команды компании Azul Systems. Тема встречи — Falcon.
Falcon — JIT-компилятор, построенный на базе инфраструктуры LLVM, уже год как является компилятором по умолчанию в виртуальной машине Zing. Новый компилятор во всю используется в продакшне и показывает существенный прирост производительности по сравнению со старым компилятором C2.
Модульность прочно обосновалась в мире javascript. Однако, при всех плюсах, писать в каждом файле одни и те же импорты — утомляет. А что, если убрать подключение часто используемых модулей в сборщик, а в коде использовать их как глобальные переменные? Выглядит, как задача для babel-плагина. Что же, давайте вместе напишем такой плагин, попутно разбираясь, как работает babel.
Инлайнинг методов – одна из наиболее важных оптимизаций в JIT-компиляторах (которые благодаря ей называются «основанными на методах» или «блочными»). Эта оптимизация расширяет область компиляции, позволяя оптимизировать несколько методов как единое целое, что повышает производительность приложений. Однако, если использовать инлайнинг методов слишком часто, время компиляции станет излишне большим, и будет сгенерировано слишком много машинного кода. И вот это скажется на производительность уже негативно.
Трассирующие JIT-компиляторы собирают не всё подряд, а только часто исполняемые пути, так называемые трейсы. С помощью этого можно получить более быструю компиляцию, уменьшить количество сгенерированного машинного кода, и улучшить его качество. В предыдущих наших работах, мы реализовали инфраструктуру для записи трейсов и трассирующий Java-компилятор, модифицируя код Java HotSpot VM. Основываясь на этой работе, мы посчитали, какой эффект инлайнинг трейсов оказывает на производительность и количество генерируемого кода.
Читать полностью »
