Will the Java Garbage Collector stop my POSIX threads created from JNI calls?

I have a time critical application that needs to send a UDP datagram on a set schedule. The tolerance for jitter is very low on the receiving side. Implementing this with a java ScheduledThreadPoolExecutor isn't adequate because when the GC does a "Stop the World" collection my thread pauses while the GC does it's job.

I would like to implement the business logic in Java while implementing the time critical portions with POSIX threads in C++ (Native environment is Linux by the way). This would allow us to save thousands of lines of code written in Java and also get the pacing we need from the native system calls.

My question is this: If I call a JNI function that creates a separate POSIX thread will that thread be "paused" when the Java GC does a "Stop the World" collection? Are there any pitfalls 开发者_开发知识库that an experienced JNI guru would like to point out with this approach or any alternative approaches one would suggest?

As always, thanks to the awesome stack overflow community!

---

My question is this: If I call a JNI function that creates a separate POSIX thread will that thread be "paused" when the Java GC does a "Stop the World" collection?

It will have no effect. STW affects java threads that needs to arrive to a safe point. A java thread into native code won't be affected either.

---

It shouldn't block the posix thread (assuming that the gc doesn't use so much cpu that other system calls would be blocked). I would think that it would block access to the posix thread from the java application but only for a very limited time.