#prog #java #article

Как мы запустили программу на Java без JavaVM, или немного про практический опыт применения GraalVM native image.

(thanks @bapho_bush)

#prog #java #python #article

Ладно бы система типов Java полна по Тьюрингу. Оказывается, к системе типов, задаваемых аннотациями типов Python, это тоже относится!

#prog #java #meme

#prog #abnormalprogramming #java #article

Сказка о типизации

#prog #java #go #meme

Source

#prog #rust #java #article

How We Migrated Our Static Analyzer From Java To Rust

Меня, правда, смущает, что правила анализа почему-то написаны на JavaScript.

<...>

We observed that the migration tripled our performance and resulted in a tenfold reduction in memory usage, <...>

To our surprise, we gained a firm grasp of the language and a clear idea of how our codebase would be mapped onto Rust within 10 days. <...> Within a month, the entire code analysis infrastructure was migrated from Java to Rust, and all customers were running on the new Rust analyzer.

<...>

Removing our dependency on the JVM and speeding up the analysis enabled us to embed the analyzer directly into the IDE. The very same lightweight and fast analyzer that runs in your CI/CD pipelines simultaneously reports coding errors and suggests fixes in your IDE in real time, <...>

#prog #go #java #article

NilAway: Practical Nil Panic Detection for Go

Инструмент для статического анализа кода на Go для обнаружения потенциальных разыменований nil-указателей. В отличие от прочих решений, решающих эту проблему, NilAway быстр, анализирует код между функциями (и даже между пакетами) и поддерживает инкрементальный анализ. При всём этом он не требует никаких аннотаций в коде.

А ранее Uber сделали аналогичный инструмент для Java, NullAway.

#prog #java #meme

#prog #java #article

3,200% CPU Utilization

TL;DR: несинхронизированный доступ к TreeMap привёл к тому, что связи между её внутренними узлами, которые обычно имеют древовидную структуру, образовали цикл, из-за чего треды зависали во время лукапа.

Автору также удалось воспроизвести этот спецэффект в C++ и в Go.

#prog

Для #java есть JEP 401: Value Classes and Objects (Preview). Value-объекты в данном случае — это объекты, у которых отсутствует идентичность. Это полезно, поскольку для многих классов, которые просто объединяют несколько полей вместе для удобства (например, LocalDateTime, или условной Point в графическом движке), наличие идентичности, отличной от совокупности значений, не имеет большого смысла.

На практике идентичность у объектов Java существует из-за того, что под них выделяется память в куче и, соответственно, у них есть уникальный адрес. Отсутствие такой идентичности позволяет генерировать более разумную реализацию оператора ==, а также делать то, что в JEP называется "heap flattening": изменение представление объекта, ссылки на который вместо хранения адреса выделенной памяти хранят значения полей объекта.

Всё это звучит хорошо, но, к сожалению, данная идея страдает от существующих элементов дизайна Java.

Первая — это повальная нуллабельность. Даже value-классы должны иметь возможность быть null, и это означает, что даже для сжатого представления один бит в ссылке должен отводиться под null-флаг. Как пишут сами авторы, массив из Integer, например, может хранить значения прямо в ссылках, но так как численные значения Integer занимают 32 бита и ещё один бит должен отводиться под null-флаг, на практике значения элементов массива будут занимать минимум по 64 бита. Это всё ещё выигрыш по сравнению с тем, что есть сейчас, поскольку это позволяет избежать индирекции на указателях и выделения 64 бита на заголовок каждого объекта в куче, но это всё ещё расточительно. Авторы явно признают эту проблему, и в разделе про дальнейшую работу есть ссылка на Null-restricted value class types JEP, но это пока лишь черновик.

Вторая проблема (которая, справедливости ради, была неочевидна индустрии на момент создания Java) — это отсутствие отслеживания алиасинга/перекрытия ссылок. В JEP авторы пишут:

Heap flattening must maintain the integrity of data. A flattened reference must always be read and written atomically, or it could become corrupted. On common platforms, this limits the size of most flattened references to no more than 64 bits.

Иными словами, выгоды от избегания аллокаций коснуться только очень маленьких объектов — особенно с учётом обязательного null-флага и паддинга под него. Но тут вообще стоит задать вопрос: зачем в принципе стоит требование атомарности обновлений ссылок? Атомарность нужна для того, чтобы избежать разрыва значений при одновременных обновлениях. Соответственно, если одновременных доступов нет, атомарность не требуется! Если бы в Java был механизм, который позволяет удостоверять, что доступ к значению уникален и остаётся уникальным в течение всего времени, пока значение остаётся достижимым (по крайней мере, для записи — многопоточное чтение безопасно и без атомарных операций), можно было бы использовать неатомарные операции для обновлений и избежать таким образом ограничений на размеры value-объектов. Можно считать это ещё одним примером к Fixing the next 10000 aliasing bugs, где инвариантом выступает целостность данных, и плюсом в копилку преимуществ отслеживания алиасинга для различных языков программирования.