Будет ли сборщик мусора Java останавливать мои потоки POSIX, созданные из вызовов JNI?

У меня есть критичное по времени приложение, которому необходимо отправить дейтаграмму UDP по заданному расписанию. Допуск на джиттер на принимающей стороне очень низок. Реализация этого с помощью java ScheduledThreadPoolExecutor неадекватна, потому что, когда сборщик мусора выполняет сбор «Остановить мир», мой поток приостанавливается, пока сборщик мусора выполняет свою работу.

Я хотел бы реализовать бизнес-логику на Java, реализуя критические по времени части с потоками POSIX на С++ (кстати, родной средой является Linux). Это позволило бы нам сохранить тысячи строк кода, написанного на Java, а также получить необходимый темп от нативных системных вызовов.

Мой вопрос заключается в следующем: если я вызову функцию JNI, которая создает отдельный поток POSIX, будет ли этот поток «приостановлен», когда Java GC выполняет сбор «Остановить мир»? Есть ли какие-либо подводные камни, на которые опытный гуру JNI хотел бы указать в этом подходе, или какие-либо альтернативные подходы, которые можно было бы предложить?

Как всегда, спасибо замечательному сообществу переполнения стека!


person LPalmer    schedule 15.04.2011    source источник
comment
Как насчет использования лучшего GC, такого как HotSpot G1 GC?   -  person Matt Ball    schedule 15.04.2011
comment
мой поток приостанавливается, пока GC выполняет свою работу. это предположение или вывод из измерения? Ответы на вопрос stackoverflow.com/questions/2085544/ утверждают, что период остановки мира короток для современных ГК.   -  person Raedwald    schedule 15.04.2011
comment
Этот GC использует параллелизм, чтобы получить большую часть прироста производительности. К сожалению, процессор, на котором это работает, представляет собой одноядерный celeron. Я не думаю, что мы что-то выиграем от G1 GC, если не обновим наш процессор, и, поскольку это высокотемпературное устройство в стиле SBC, мы пока застряли с нашим маленьким celeron.   -  person LPalmer    schedule 15.04.2011
comment
Если вы настолько чувствительны к джиттеру, что подумываете о реализации секции синхронизации изначально, то любая пауза stw бесполезна. В этот момент вам нужно учитывать джиттер операционной системы, например, возникающий из-за прерываний.   -  person Matt    schedule 15.04.2011
comment
Моя чувствительная к джиттеру синхронизация находится в диапазоне от 5 до 10 мс. GC может прервать весь процесс на срок до 300 мс. Это слишком долго. ОС не заблокирует мою программу на 300 мс.   -  person LPalmer    schedule 15.04.2011
comment
В зависимости от поведения распределения, размера кучи и доступной памяти, я бы сказал, что у вас есть шанс получить паузу в 5-10 мс. Это не может быть гарантировано, конечно.   -  person Matt    schedule 15.04.2011
comment
@Raedwald Период остановки мира измеряется от 150 до 300 мс. Что касается современного GC, я использую последнюю версию java 1.6 GC, настроенную на одновременную развертку меток, и с несколькими другими флагами, которые мы определили как лучшие для нашего приложения.   -  person LPalmer    schedule 16.04.2011
comment
Распределение @Matt - неприятный вопрос. Помните, что я не единственный, кто размещает объекты в памяти. Объекты также выделяются различными частями Java API, поэтому я не могу ПОЛНОСТЬЮ контролировать, сколько объектов создается.   -  person LPalmer    schedule 16.04.2011
comment
@ Мэтт, мой опыт с G1 - утечка памяти.   -  person bestsss    schedule 16.04.2011
comment
@bestsss, настройка IME G1 плохо документирована, и я обнаружил, что CMS превосходит ее при измерении по времени STW (и, что интересно, ParNew сделал приложение заметно быстрее, чем работающее под G1). Я настроил чувствительное к задержке приложение так, чтобы 98-99% пауз приходилось на 5-10 мс, полагаясь на то, что оно работает только 24/6 и может избежать полного gc в эти 6 дней.   -  person Matt    schedule 16.04.2011


Ответы (2)


Он не должен блокировать поток posix (при условии, что gc не использует так много процессора, что другие системные вызовы будут заблокированы). Я бы подумал, что это заблокирует доступ к потоку posix из java-приложения, но только на очень ограниченное время.

person joekarl    schedule 15.04.2011

Мой вопрос заключается в следующем: если я вызову функцию JNI, которая создает отдельный поток POSIX, будет ли этот поток «приостановлен», когда Java GC выполняет сбор «Остановить мир»?

Это не будет иметь никакого эффекта. STW влияет на потоки Java, которым необходимо достичь безопасной точки. Поток Java в собственный код также не будет затронут.

person bestsss    schedule 15.04.2011