Why to call a fiber inside JNI throws a StackOverflow in JVM?

Question

I think this is a difficult question also here. Anyway i want try.

I realized a mini project JNI porting native boost fibers inside Java.

This is JNI interface

inline void execute(JNIEnv * env,jobject runnable,jmethodID mid){
 cout <<  " 31---"  << endl;
 env->CallVoidMethod(runnable, mid);
  cout <<  " 32---"  << endl;
}

/*
 * Class:     java_ext_concurrent_fiber_NativeFiber
 * Method:    run
 * Signature: (Ljava/lang/Runnable;)J
 */
JNIEXPORT void JNICALL Java_ext_concurrent_fiber_NativeFiber_run
  (JNIEnv * env, jclass clazz, jobject runnable){
cout <<  " 1---"  << endl;
   jclass cls = env->GetObjectClass( runnable);
   cout <<  " 2---"  << endl;
   jmethodID mid = env->GetMethodID( cls, "run", "()V");
cout <<  " 3---"  << endl;

env->CallVoidMethod(runnable, mid);
  boost::fibers::fiber fiber(execute,env,runnable,mid);

  cout <<  " 3---"  << endl;

  }

this is the java Test

public class Test {
    public static void main(String[] args) throws InterruptedException {

        NativeFiber fiber=new NativeFiber(new Runnable() {
            @Override
            public void run() {


                System.out.println("hello");
            }
        });
        fiber.start();


    }
}

If i execute this code

throws StackOverflowException

If i remove fiber.join() and i add fiber.detach();

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f5a37017f1f, pid=16559, tid=0x00007f5a38522700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x6d7f1f]  jni_CallVoidMethodV+0x3f
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /data/git/concurrent/hs_err_pid16559.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp

Yes but it is not the problem because actually i dont use that address. Anyway there the following problem how to retrieve a fiber in a second time. Maybe by Id ... but how? — Bianca Mattiolo, Dec 24 '17 at 10:53

score 0 · Answer 1 · answered Dec 24 '17 at 14:05

Possibly because the stack of Fibers are too small for Java.

However, it's really ill-advised to run JVM/JRE code on fibers without there being explicit support for that.

If you have uncovered a part of the JVM specification that explicitly allows it, and you know that the parts of the JRE that you depend on all are safe for use on fibers, you can obviously disregard these words of caution

As it happens, JVM/JRE may contain any number of assumptions based on the threading model. Such as the use of thread-local static instances being safe for unsynchronized access. This will break the assumption and therefore lead to unspecified behaviour.

If you need Fibers, look at a JVM-blessed way to achieve them (I cannot imagine there isn't a popular library to do this).

I tried to encrease fiber stack until 16 mb. Same error. It seams there is not way to communicate from java to c++ . It works just if you pass basic data type but not java object with callbacks( if you call java inside a fiber). If you use java fibers with JNI works badly because there is thread locks in c++, if you use c++ fibers dont works.Fibers are creating a big problem with interoperability — Bianca Mattiolo, Dec 24 '17 at 16:10

Why to call a fiber inside JNI throws a StackOverflow in JVM?

1 Answers1