Guava, Graal and Partial Escape Analysis

Recently java 10 release happened - in fact, Graal was available earlier, but now it is more easy to access and use it - Congratulations, you're running #Graal! - just add a couple options:

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

What does it can provide for us and what kind of enhancements we can expect to get, and more over - what dirty-hacks could be dropped ?

build hsdis with Java 10 on MacOsX

instructions to build hsdis with java 10 - based on instructions for building hsdis on OSX (with java 9)

$ hg clone http://hg.openjdk.java.net/jdk/jdk10/
$ cd jdk10/src/utils/hsdis
$ wget https://ftp.gnu.org/gnu/binutils/binutils-2.28.tar.bz2 
$ tar jxf binutils-2.28.tar.bz2
$ make BINUTILS=binutils-2.28 ARCH=amd64
$ sudo cp build/macosx-amd64/hsdis-amd64.dylib /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/lib/server

Note: despite of hsdis/README it does NOT compile with binutils-2.17, nor binutils-2.19.1 neither with latest binutils-2.30. binutils-2.28 works fine on High Sierra.

Java: All flags

Just to share my note - print out all jvm flags

$ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

Java unsafe: copyMemory aligned vs unaligned

Давеча переводя проект на новые рельсы стала падать сборка - тесты проходят, а вот jvm крешится.

Первое подозрение упало на наш alloc / dealloc поверх Unsafe (да-да, кровь-кишки-камаз) - но в итоге все же стало ясно, что наши руки чистые и вина реально на C2 компиляторе и трова стала тому причина - на эту тему две ошибки в C2 компиляторе: JDK-8081379 и по мотивам этого же JDK-6675699.

Однако, пока я винил наш alloc/dealloc смотрел - а не пытаемся ли мы деаллоцировать чего не нужного, соответственно стал писать адреса выделенной памяти и размеры.
Удивило, что очень много объектов без выравнивания по длине - например, 27 байт или там 253.

Читаем sun.misc.Unsafe#copyMemory и тут ребята заботливо пишут:

    /**
     * Sets all bytes in a given block of memory to a copy of another
     * block.
     *
     * This method determines each block's base address by means of two parameters,
     * and so it provides (in effect) a double-register addressing mode,
     * as discussed in {@link #getInt(Object,long)}.  When the object reference is null,
     * the offset supplies an absolute base address.
     *
     * The transfers are in coherent (atomic) units of a size determined
     * by the address and length parameters.  If the effective addresses and
     * length are all even modulo 8, the transfer takes place in 'long' units.
     * If the effective addresses and length are (resp.) even modulo 4 or 2,
     * the transfer takes place in units of 'int' or 'short'.
     *
     * @since 1.7
     */

Более того, мистер Коваль накинул еще:

мол не только же длина, но и смещение играют роль - н.р если даже читать long, но он будет смещен на 1 байт относительно слова - то в итоге будут прочитаны два long.

обновление 2015-02-13:

Итак, куда же идет Unsafe.copyMemory ?

Это нативный jvm вызов:
копаем в сторону unsafe.cpp: Unsafe_CopyMemory
потом Copy::conjoint_memory_atomic

и вот от момент откровения:

  uintptr_t bits = (uintptr_t) src | (uintptr_t) dst | (uintptr_t) size;

  if (bits % sizeof(jlong) == 0) {
    Copy::conjoint_jlongs_atomic((jlong*) src, (jlong*) dst, size / sizeof(jlong));
  } else if (bits % sizeof(jint) == 0) {
    Copy::conjoint_jints_atomic((jint*) src, (jint*) dst, size / sizeof(jint));
  } else if (bits % sizeof(jshort) == 0) {
    Copy::conjoint_jshorts_atomic((jshort*) src, (jshort*) dst, size / sizeof(jshort));
  } else {
    // Not aligned, so no need to be atomic.
    Copy::conjoint_jbytes((void*) src, (void*) dst, size);
  }

Если кратко, то bits тогда и только тогда будет кратен размеру long, когда и адрес источника, и адрес цели, и длина блока будут кратны размеру long.

benchmark.
проверяет копирование в многопоточном режиме - 4 нитки.

Изначально производилось копирование из одного общего (для всех нитей) куска памяти в другой общий кусок памяти - и от этого получались странные цифры, что копирование 8 байт со смещением 0 такое же, как и копирование 8 байт со смещением 3 байта.

В моем приложении другой шаблон использования - копирование происходит из общего куска памяти в свой (н-р локальный массив байт) локальный кусок памяти.

Результаты для 4х ниток:

Benchmark                    Mode  Samples   Score   Error  Units
copyMemory253Bytes           avgt       15  13.023 ± 0.376  ns/op
copyMemory253BytesOffset3    avgt       15  13.189 ± 0.512  ns/op
copyMemory256Bytes           avgt       15  11.091 ± 0.304  ns/op
copyMemory256BytesOffset7    avgt       15  13.185 ± 0.066  ns/op

copyMemory27Bytes            avgt       15   9.034 ± 0.058  ns/op
copyMemory32Bytes            avgt       15   5.567 ± 0.154  ns/op
copyMemory32BytesOffset3     avgt       15   7.779 ± 0.080  ns/op

copyMemory4Bytes             avgt       15   6.801 ± 0.068  ns/op
copyMemory4BytesOffset3      avgt       15   7.760 ± 0.091  ns/op

copyMemory8Bytes             avgt       15   6.763 ± 0.044  ns/op
copyMemory8BytesOffset1      avgt       15   8.398 ± 0.154  ns/op
copyMemory8BytesOffset3      avgt       15   8.368 ± 0.083  ns/op
copyMemory8BytesOffset5      avgt       15   8.396 ± 0.079  ns/op

readByteOffset0              avgt       15   3.067 ± 0.153  ns/op
readByteOffset3              avgt       15   3.024 ± 0.044  ns/op

readIntOffset0               avgt       15   3.001 ± 0.037  ns/op
readIntOffset3               avgt       15   3.051 ± 0.150  ns/op

readLongOffset0              avgt       15   2.997 ± 0.042  ns/op
readLongOffset3              avgt       15   2.993 ± 0.056  ns/op

и для 1 нитки

Benchmark                    Mode  Samples   Score   Error  Units
copyMemory253Bytes           avgt       15  13.392 ± 0.580  ns/op
copyMemory253BytesOffset3    avgt       15  12.903 ± 0.304  ns/op
copyMemory256Bytes           avgt       15  11.195 ± 0.405  ns/op
copyMemory256BytesOffset7    avgt       15  13.446 ± 0.422  ns/op

copyMemory27Bytes            avgt       15   9.136 ± 0.266  ns/op
copyMemory32Bytes            avgt       15   5.513 ± 0.190  ns/op
copyMemory32BytesOffset3     avgt       15   7.830 ± 0.273  ns/op

copyMemory4Bytes             avgt       15   6.826 ± 0.204  ns/op
copyMemory4BytesOffset3      avgt       15   7.757 ± 0.223  ns/op

copyMemory8Bytes             avgt       15   6.897 ± 0.221  ns/op
copyMemory8BytesOffset1      avgt       15   8.534 ± 0.276  ns/op
copyMemory8BytesOffset3      avgt       15   8.482 ± 0.285  ns/op
copyMemory8BytesOffset5      avgt       15   8.403 ± 0.262  ns/op

readByteOffset0              avgt       15   2.971 ± 0.104  ns/op
readByteOffset3              avgt       15   3.009 ± 0.115  ns/op

readIntOffset0               avgt       15   3.001 ± 0.125  ns/op
readIntOffset3               avgt       15   3.032 ± 0.113  ns/op

readLongOffset0              avgt       15   3.010 ± 0.100  ns/op
readLongOffset3              avgt       15   3.060 ± 0.094  ns/op

Т.е действительно для копирования очень важно, чтобы всё было по восьмерке, тогда как для чтения это не имеет значения. ... meten is weten // голл. поговорка: измерение это знание

java: конференция jpoint

Осталось чуть больше недели до независимой java конференции jpoint, организованной энтузиастами Java User Group, которая состоится 5го апреля 2013 года в конгрессном центре “ПетроКонгресс” по адресу Санкт-Петербург, ул. Лодейнопольская, д. 5.

Святые угодники! Кто все эти люди ?!?

Я буду рассказывать о шишках и фишках, которые мы набили с garbage collectorом, как мы научились не мешать друг другу работать, зачем родился на свет garbage free logger, а так же о своих наблюдениях и рекомендациях в оптимизации приложений с оглядкой на gc, которые, надеюсь, будут полезные другим разработчикам.

Организаторы сознательно сделали несколько шагов объявив конференцию для middle/senior разработчиков:

• Участие для слушателей в конференции платное. Деньги не космические, но это создаёт порог отсева толпы, пришедшей за халявой в виде бесплатных ручек и блокнотов
• Подбор тем докладов и самих докладчиков: определённо темы докладов для людей «глубоко женатых», т.е для тех, у кого за плечами гораздо больше, чем hello world и пары свистелок.

Мой предварительный план докладов, которые хочу послушать:

• Динамическое обнаружение гонок в многопоточных Java-программах - ребята из Devexperts, явно есть чему поучиться у них и узнать новые способы варки автогеномтонкой работы в java
• Java Runtime: повседневные обязанности виртуальной машины Java - очень мне близка тематика по духу, приятно удивлён, что и у нас есть горячие головы, которые лобзиком выпиливают gc из jvm.
• и быть может, холивное Eclipse vs Intellij IDEA
• хотел бы ещё сходить послушать GC: Friend or foe, но ведь не дадут послушать...

Ещё раз хотелось бы послать лучи поддержки организаторам - у нас всё получится !

Дополнение. Организаторы обещают сделать видеозаписи докладов, которые после будут доступны в интернетах. Не спрашивайте меня когда, сколько и по чём.

P.S. Да, и регистрация уже закрыта.

java: who has eaten my cpu ?

Приходит давеча коллега и показывает запущенное простенькое java приложение, которое выжирает > 100% cpu без какой-либо на то видимой причины.

Святые угодники! что делать ?

java: Adaptive throttling, Part 1

Типичная проблема, которая возникает при обработке большого потока сообщений:

- нельзя пропихнуть большого слона через маленькую трубу, т.е. обработка сообщений не успевает «проглотить» все сообщения


При этом существуют некоторые ограничения на поток данных :

• поток не равномерный и состоит из событий разного типа
• количество типов событий заранее не известно, но конечное число
• каждый тип события имеет свою актуальность во времени
• все типы событий имеют равный приоритет

На диаграмме приведён пример разрешения проблемы: нагребатор™ работает на нитке T₁, а следовательно разгребатор™ на нитке T₂

• за время обработки события типа A успевают прийти новые события как типа B, так и A
• после обработки события типа B необходимо обработать наиболее актуальное событие типа A

Проблема осложняется ещё тем, что может быть несколько нагребаторов™, при этом каждый нагребатор™ может порождать только события одного типа; так и есть потребность в нескольких разгребаторах™ - при этом

Терминология. Stream есть поток данных, тогда как thread есть нитка или нить выполнения. И не стоит путать потоки с нитками.

java: nanoTime

Пока одни заливали соляру в трактор, мы продолжаем копаться в своём.

Тёма очень хорошо написал о измерении времени в java с ссылками на источники, так, что казалось бы и добавить нечего, но вставлю я свои пять копеек.

Все мы хорошо знаем метод System.nanoTime()

java: garbage less

За время написания gflogger и борьбой за low latency в java накопился некоторый опыт о том как меньше плодить мусора и тем самым меньше нагружать сборщик мусора, и как следствие, меньше влиять на производительность самого приложения.

Такому тонкому троллиподходу придумали специальный термин garbage less design.

Впрочем, существую и некоторые другие вариации как заставить garbage collector меньше мешать нам жить.

gflogger 0.0.9.x

Garbage Free Logger добрался до версии 0.0.9.x .

Надо сказать, что версия полна изменениями, допиливаниями и добавлением мелких, но важных мелочей, которые активно используются.

Но обо всём по порядку.

java: 64 vs 32 jvm

На конференции Java One 2012 Moscow я услышал интересную мысль от инженера Sun Oracle Владимира Иванова, что

64 bit jvm даст прирост производительности даже для приложений с размером кучи менее 4Gb даром.

С чего бы это вдруг ?

run script

So, for many java core applications people use self made run-scripts. Most of them are some kind of sh/bash script that run java process with required arguments, classpath and so on and so on. After process is started script usually makes a pid file to track just created java process.

Many our java applications uses spring framework that's why we use Boostraper which helps us for many cases.

run script output

java: cache padding

Думаю, что многие уже наслышаны о магии cache padding в disruptor'е.

Однако, куда более интересный факт - наличие cache padding'а уже в самом jdk 1.5

garbage free logger

We do usually log lots of messages, for instance - for further investigation in case of outage. There are lots of pros and cons - for many reasons log files are usually in more or less human readable format. For low latency applications it's a sort of waste of time as it put a load onto the system via garbage collector and app suffers from stop-the-world pauses.

java: autoboxing и ==

С появлением java 5 появилась и такая вещь как auto boxing, на мой взгляд штука скорее вредная, чем полезная, но не суть.

Наверняка многие java программисты сходу могут ответить на вопрос «какой будет результат ?»

        Integer a = 100;
        Integer b = 100;
        Integer c = 300;
        Integer d = 300;
        
        System.out.println(a == b);
        System.out.println(c == d);

Тем более, что многие книги, как то Java Puzzlers, упоминают об этом.

Spring Boostrap

We uses spring framework within each our project. I would like to share some small and useful tricks we use in our Bootstrap class.

To load any xml spring context you have to run smth like

try {
    final ClassPathXmlApplicationContext ctx = 
        new ClassPathXmlApplicationContext(
            new String[] {"application-context.xml"});
} catch ( final Throwable th) {
    log.error("Unable to start the context : " + th.getMessage(), th);
}

It's enough in the most cases.

java: деградация пула строк

Наверняка многие java программисты знают о существовании пула строк, который хранится в PermGen.

Кроме всего прочего каждая строка, которая была получена через

new String(data);

можно привести к каноническому представлению посредством вызова метода intern().

Однако, доступ к полу строк может деградировать из-за большого кол-ва строк в пуле.

В своей статье вы уверены, что знаете про строки все? автор упоминает, что сложность intern() есть O(N), где N - размер пула строк.

Надо сказать меня сильно удивило - т.к. ещё в стародавние времена, когда стали доступны исходники sun hotspot jvm 1.4 (кстати, именно из них собирался blackdown-jdk) помню, что на уровне c++ пул строк сделан как Hashtable, у которого, как известно, сложность поиска O(1) - т.е константа.

Serialization graph

Стандартная сериализация в java обладает рядом недостатков (см. Effective Java 2nd edition, автор Josh Bloch стр. 289), среди которых: медленная сериалазиция (см. jvm-serializers benchmarks) и сохранение полного графа объектов.
Однако, идея сохранения графа имеет и положительный аспект.

Lock Coarsening, Biased Locking, Escape Analysis and others

Оптимизационные трюки, используемые при динамической компиляции jit'ом в java 6. В java 6 была существенно изменена (по сравнению с java 5) работа блокировок, существенно облегчив их, в java6u14 появился escape-анализ, который работает по-умолчанию, а так же много других интересных подходов.

Hazelcast

hazelcast
In-Memory Data Grid for Java
hazelcast project on Google Code; Hazelcast.com
hazelcast documentation

Краткая история:

• Start-up, основан 2008
• Open source бизнес модель. Получение прибыли на консалтинге и поддержке самого Hazelcast
• Более 100 пользователей, в основном в США и в Европе