Здравствуйте, Sinclair, Вы писали:

S>·>А если она использует тот же JDK-шний io, то всё ок.
S>Ну я не особый знаток джавного ландшафта; но помимо стандартного IO в виде файлов/сокетов могут быть всякие сторонние решения.
S>То есть понятно, что если у нас есть какой-нибудь JDBC-шный драйвер, который внутре лезет на сервер через стандартный сокетный API, то всё зазеленеет само.
S>А если там какой-то high performance код, который работает с сетевой карточкой в чистой юзермоде, то чудес не случится.
Ну как бы да. С другой стороны, вылизанного hiperf кода не так уж и много. Тем более там скорее всего будет на нутро будет завязано на определённые режимы операционки и железа, ну чтоб cpu affinity, irq, numa. Но это же только транспорт в приложении, один железный поток, как правило логически относительно примитивный, а потом он может выдавать это толпе виртуальных, которые запутанную бизнес-логику делают.

S>·>Да. Ещё расчёт на то, что в java принято писать pure-решения. В отличие от того же c#, где на каждый чих DllImport.
S>Я так и подумал. Получается, тут преимущество java является обратной стороной её недостатка — трудности интеграции с нативным hi-perf кодом помогают оптимизировать low-perf код.
Java упор на managed делает. А шарп пытается на двух стульях усидеть.
Впрочем, java тоже аккуратно добавляет безопасный FFM.

S>·>Да. Возможная грабля, похоже. В смысле вряд ли оно это сможет обнаружить как-то. Но ведь реальные треды никуда не уходят. Если есть такой код, который плотно взаимодействует с нативом и делает всякие странные вещи, то его можно всё ещё пускать на реальных тредах.
S>Тут главное — понять, можно ли пускать. В джаве популярны стеки глубиной в сотни вызовов. Вполне невинный гражданский код, который вызывает что-то из pure-java пакета, может через сотню-другую вызовов упереться в какой-то JNI, да ещё и зависимым от конфигурации образом. То есть в домашних тестах всё будет летать огнём, а в проде какая-нибудь экзотическая зависимость неожиданно стрельнет .
Вроде добавляют диагностику какую-то для отслеживания pinned-потоков, что будет индикацией jni-вызовов.

S>Я не спец в low-level; поэтому не знаю — есть ли способ определить, лазил ли сделанный нами вызов натива в TLS, чтобы сделать хотя бы fail fast с внятной диагностикой (вместо чтения мусора).
В смысле внутри нативного колла? Не знаю тоже, думаю от операционки зависит.

Здравствуйте, Sinclair, Вы писали:

S>·>А если она использует тот же JDK-шний io, то всё ок.
S>Ну я не особый знаток джавного ландшафта; но помимо стандартного IO в виде файлов/сокетов могут быть всякие сторонние решения.
S>То есть понятно, что если у нас есть какой-нибудь JDBC-шный драйвер, который внутре лезет на сервер через стандартный сокетный API, то всё зазеленеет само.
S>А если там какой-то high performance код, который работает с сетевой карточкой в чистой юзермоде, то чудес не случится.
Ну как бы да. С другой стороны, вылизанного hiperf кода не так уж и много. Тем более там скорее всего нутро будет завязано на определённые режимы операционки и железа, ну чтоб cpu affinity, irq, numa. Но это же только транспорт в приложении, один железный поток, как правило логически относительно примитивный, а потом он может выдавать это толпе виртуальных, которые запутанную бизнес-логику делают.

S>·>Да. Ещё расчёт на то, что в java принято писать pure-решения. В отличие от того же c#, где на каждый чих DllImport.
S>Я так и подумал. Получается, тут преимущество java является обратной стороной её недостатка — трудности интеграции с нативным hi-perf кодом помогают оптимизировать low-perf код.
Java упор на managed делает. А шарп пытается на двух стульях усидеть.
Впрочем, java тоже аккуратно добавляет безопасный FFM.

S>·>Да. Возможная грабля, похоже. В смысле вряд ли оно это сможет обнаружить как-то. Но ведь реальные треды никуда не уходят. Если есть такой код, который плотно взаимодействует с нативом и делает всякие странные вещи, то его можно всё ещё пускать на реальных тредах.
S>Тут главное — понять, можно ли пускать. В джаве популярны стеки глубиной в сотни вызовов. Вполне невинный гражданский код, который вызывает что-то из pure-java пакета, может через сотню-другую вызовов упереться в какой-то JNI, да ещё и зависимым от конфигурации образом. То есть в домашних тестах всё будет летать огнём, а в проде какая-нибудь экзотическая зависимость неожиданно стрельнет .
Вроде добавляют диагностику какую-то для отслеживания pinned-потоков, что будет индикацией jni-вызовов.

S>Я не спец в low-level; поэтому не знаю — есть ли способ определить, лазил ли сделанный нами вызов натива в TLS, чтобы сделать хотя бы fail fast с внятной диагностикой (вместо чтения мусора).
В смысле внутри нативного колла? Не знаю тоже, думаю от операционки зависит.