Рубрика «системное программирование» - 59

ОС Фантом — экспериментальная операционная система, содержащая на прикладном уровне виртуальную байткод-машину в персистентной оперативной памяти.

Один из двух ключевых запланированных для ОС Фантом путей миграции существующего кода — преобразование байткода Java в байткод Фантом.

Надо сказать, что эти виртуальные машины изрядно, хотя и совершенно случайно, похожи. Виртуальная машина Фантома была спроектирована тогда, когда про Явскую я ещё ничего не знал, но, наверное, сходство целей привело к сходству принятых решений.

Обе машины — стековые. Обе оперируют двумя отдельными стеками — стеком для работы с объектами (на стеке лежат только ссылки), и бинарным стеком — для вычислений. Машина Фантома имеет также отдельные стеки для фреймов функций и ловушек исключений. Как эта часть устроена в JVM, я не знаю до сих пор, но полагаю, что вряд ли кардинально отличным образом.

Естественно, что и набор операций стековых машин местами схож как две капли.

Но, безусловно, есть и весьма существенные отличия.

Во-первых, виртуальная машина Фантома предназначена для работы прикладного кода в менее дружественной среде. Ява исходит из того, что каждая программа живёт в отдельном адресном пространстве, и всё, что вокруг — “наш” код. Фантом допускает прямые вызовы между приложениями разных пользователей и разных программ, что требует более жёсткого отношения к некоторым аспектам виртуальной машины, включая тот же вызов, да и интерфейс объекта вообще. Например, мы не можем полагаться на то, что вызванный метод ведёт себя “прилично” — нельзя давать ему доступ в свой стек, нельзя полагаться на наличие или отсутствие возвращаемого значения. Нельзя гарантировать различие между методом, функцией и статической функцией. То есть, мы можем предполагать, что именно мы вызываем, но что нам «подсунули» с той стороны — неизвестно.

В силу всего сказанного, вызов в Фантоме унифицирован абсолютно — это всегда вызов метода (есть this и есть класс), и всегда возвращается значение, которое для void метода равно null и явно уничтожается вызывающим кодом. Это гарантирует, что какая бы ошибка вызова не случилась, что бы не подвернулось в качестве предмета вызова, протокол вызова и возврата будет соблюдён.
Читать полностью »

image

Как-то так получилось, что я написал на Хабре уже несколько статей о библиотеках для хуков. Первая была об общих принципах и реализации на базе Detours, вторая — о более дешевой (но не менее функциональной) библиотеке madCodeHook. Сегодня я расскажу об ещё одном варианте — библиотеке Deviare от компании Nektra. «Ещё одна точно такая же библиотека для хуков?» — спросите вы. «Такая же, да не такая» — отвечу я. У Deviare есть несколько особенностей, отличающих её и от Detours и от madCodeHook и делающей её в некоторых случаях намного более полезной.
Читать полностью »

Так уж вышло, что у нас на складе оказалось довольно много микроконтроллеров EFM32ZG110F32, это серия Zero Gecko от компании SiLabs. Контроллеры классные, но пока не особенно популярны, потому я и пишу эту статью.

Статья про микроконтроллер EFM32ZG110F32 - 1
На правах рекламы мы предлагаем вот такой набор: ARM Cortex-M0+, 32 Кбайт Flash, 4 Кбайт ОЗУ, DMA, I2C, UART, USART, 12-разрядный АЦП, токовый ЦАП, компаратор, аппаратный счетчик импульсов, часы реального времени и разные штуки для снижения энергопотребления в корпусе QFN-24 за $0.96.

Под катом длинный пост с подробным обзором кристалла и отладочной платы, описанием доступных средств программирования и отладки. Приведены примеры работы с различными периферийными блоками кристалла, используются фирменные средства разработки и платформа mbed от ARM.
Читать полностью »

На что стоит променять Cortex-M3? - 1ARM Cortex-M3 — это, пожалуй, самое популярное на сегодняшний день 32-разрядное процессорное ядро для встраиваемых систем. Микроконтроллеры на его базе выпускают десятки производителей. Причина этому — универсальная, хорошо сбалансированная архитектура, а следствие — непрерывно растущая база готовых программных и аппаратных решений.

Ругать Cortex-M3, в общем-то, не за что, но сегодня я предлагаю подробно рассмотреть Cortex-M4F — расширенную версию всеми любимого процессорного ядра. Перенести проект с микроконтроллера на базе Cortex-M3 на кристалл на базе Cortex-M4F довольно просто, а для ряда задач такой переход стоит затраченных усилий.

Под катом краткий обзор современных Cortex'ов, обстоятельное описание блоков и команд, отличающих Cortex-M4F от Cortex-M3, а также сравнение процессорных ядер на реальной задаче — будем измерять частоту мерцания лампы на микроконтроллерах с разными ядрами.

Читать полностью »

Архитекторы процессоров архитектуры x86 исторически были против предоставления программистам возможности непосредственного управления кэшем. Один как-то сказал мне в 2009 году — «никогда мы этого не сделаем, кэш всегда должен быть прозрачным для программиста». Некоторые RISC процессоры представляют архитектурную возможность управления данными/кодом, который окажется в кэше. И вот, наконец-то, нечто подобное появилось и в архитектуре x86 (начиная с Broadwell*).
Читать полностью »

Каждый С-программист с опытом накапливает привычный багаж техник и идиом. Зачастую бывает сложно понять, как сделать то же самое в новом языке. Так вот, вашему вниманию предлагается коллекция распространенных паттернов на C и их эквивалентов на D. Если вы собираетесь перевести свою программу с C на D или ещё сомневаетесь стоит ли это делать, то эта статья для вас.

Читать полностью »

скриншот консоли, который рвет шаблон

На картинке выше вы можете наблюдать, как ls считает, что linkylink/.. это не то же самое, что текущий каталог. При этом cd, кажется, с ним не согласен.

Начну рассказ со всем знакомых веб-адресов, которые похожи на системные пути.

Две точки в путях URI (в вебе)

Читать полностью »

Rust и парадокс Блаба - 1Несколько недель назад я наткнулся на сравнительный анализ Rust, D и Go от Андрея Александреску. Андрей, уважаемый член сообщества C++ и главный разработчик языка программирования D, нанес Rust сокрушительный удар под конец своего повествования, высказав нечто, что выглядит довольно проницательным наблюдением:

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

После нескольких встреч с Андреем, увидев некоторые из его выступлений, я убедился, что он любит подшучивать. Тем не менее, давайте проглотим наживку. Эта шутка смешная только потому, что она выглядит смешной, или может быть потому, что в ней только доля шутки?Читать полностью »

Разрабатывая CRIU, мы поняли, что текущий интерфейс получения информации о процессах не идеален. К тому же, подобная проблема была успешно решена для сокетов. Мы попытались перенести эти наработки на процессы и получили достаточно хорошие результаты, о которых вы узнаете, дочитав эту статью до конца.

Недостатки текущего интерфейса

Прочитав заголовок, возникает вопрос:”A чем же старый интерфейс не угодил”? Многие из вас знают, что сейчас информация о процессах собирается по файловой системе procfs. Здесь каждому процессу соответствует директория, которая содержит несколько десятков файлов.

$ ls /proc/self/ 
attr             cwd      loginuid    numa_maps      schedstat  task
autogroup        environ  map_files   oom_adj        sessionid  timers
auxv             exe      maps        oom_score      setgroups  uid_map
cgroup           fd       mem         oom_score_adj  smaps      wchan
clear_refs       fdinfo   mountinfo   pagemap        stack
cmdline          gid_map  mounts      personality    stat
comm             io       mountstats  projid_map     statm
coredump_filter  latency  net         root           status
cpuset           limits   ns          sched          syscall

Читать полностью »

В данной статье я бы хотел рассказать о собственном опыте оптимизации выполнения множества регулярных выражений при помощи системы hyperscan. Так вышло, что при разработке своего спам-фильтра rspamd я столкнулся с необходимостью портировать большой объем старых правил, написанных для spamassassin за несколько лет работы. Моим первым решением было написать плагин, который бы читал эти правила и строил из них синтаксическое дерево. Затем на этом дереве выполнялись различные оптимизации, чтобы сократить общее время выполнения (об этом я даже делал небольшую презентацию).

К сожалению, в ходе эксплуатации выяснилось, что pcre все равно являются узким местом, и на больших письмах этот набор правил работает слишком медленно. Выяснилось, например, что на письме размером в мегабайт pcre проверяет около гигабайта (!) текста. Различные трюки, вроде ограничения количества текста для регулярных выражений, оказывали негативное влияние на срабатывания правил, а оптимизации pcre путем интенсивного использования jit fast path через pcre_jit_exec оказались слишком опасными — некоторые старые выражения были откровенно некорректными и в сочетании с некорректным входным текстом, например, содержащим «битые» UTF8 символы, приводили к воспроизводимым багам с повреждением стека программы. Однако на конференции highload мы поговорили со Славой Ольховченковым, и он мне посоветовал посмотреть на hyperscan. Далее я перейду к сути и расскажу, что из этого получилось.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js