Lines Matching full:jni
74 and on requests coming in from native code (e.g. all JNI functions).
77 Native methods must use JNI calls to modify object references to avoid
78 clashes with the GC. JNI doesn't provide a way for native code to access
80 so it should be possible to fully control access through JNI.
102 code makes JNI calls, there is no risk of suspending while holding internal
564 * Could be an unusual JNI thread-attach thing.
608 * stopped, so these should be Thread objects or JNI-attached threads
731 #if 0 /* bad things happen if they come out of JNI or "spuriously" wake up */
750 * JNI registration.
760 /* create a "fake" JNI frame at the top of the main thread interp stack */
1027 * The JNI local ref table *must* be fixed-size because we keep pointers
1234 * place to hang JNI local references. The VM spec says (v2 5.2) that the
1258 * load it. This makes life easier over in JNI FindClass (though it
1262 * of necessity coming before JNI is initialized, and we're not quite
1287 * executing interpreted code. This gives us a place to hang JNI local
1630 * Add a JNI context.
1761 * JNI AttachCurrentThread implementation.
1901 * Used for internally-created threads and JNI's AttachCurrentThread.
1974 * Create a "fake" JNI frame at the top of the main thread interp stack.
1976 * the debugger something to show. It is essential for the JNI-attached
2120 * When we get here the interpreted stack should be empty. The JNI 1.6 spec
2124 * we only have to worry about explicit JNI calls to MonitorEnter.)
2145 * could happen with an explicit JNI detach call.)
2148 * zero, while a JNI-attached thread will have the synthetic "stack
2176 * frames, the only thing left are the monitors held by JNI MonitorEnter
2272 * Lose the JNI context.
2822 * We do need to hold the thread list because of JNI attaches.
2914 * We do need to hold the thread list because of JNI attaches.
3253 * This is useful when attaching a thread through JNI.
