> Stephen Crawley wrote: > > > > > Those of you have been following the Kissme mailing list will know > > that we've had a long-standing problem with Kissme garbage collection > > and IO. In a nutshell, the Kissme garbage collector can only run > > when all threads are within a "GC point". Normal Java code regularly > > enters (and exits) GC points, and native code will get there eventually. > > > As far as I understand one of basic concepts behind JNI, idea behind > local/global references mess one exactly meant to provide a help for gc. > Call to native method can be marked as safe (all call areas have to be > fully resolved to allow gc for upper frames). Inside JNI, nothing bad > can happen - all references to java objects are managed through JNI > itself, which is fully under your control.
I understand this. Unfortunately it does not work for us at the moment because Kissme's native methods do not "obey the rules", and are hence not GC safe. > Why careful design of JNI layer cannot solve the problem here ? I'm sure it would have done, but that's not where we are at right now. We have a large amount of JVM code whose implementation we cannot really trust. To move forward in the short term, we need to do something like this. > You cannot expect all people out there to write their JNI libraries > wrapping any potentially blocking calls into your calls (I'm talking > about third party libraries). You are correct. However, support for direct IO from third party JNI libraries is not a high priority for us right now. -- Steve _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
