David P Grove writes: > The historical reasons why Jikes RVM uses green threads aren't that > relevant to this list, so I'll just direct any one who cares to recent > discussion on the Jikes RVM core list. Personally, I think Jikes RVM > should be moving to native threading mainly to make it easier to run apps > with native code that assumes native threading, but that's not relevant to > your question. > > > Maybe you know something I don't. Is there any wordage in the JNI > > spec that forbids blocking calls, or suggests that this might be > > problematic? Is there any wordage in the JNI spec that allows the > > Jikes RVM to behave in the way that it does with repect to blocking > > calls? > > The JNI spec 8.1.5 basically says that if you are writing native code, and > your native code assumes a threading model that is different from the one > used by the JVM then you shouldn't expect your application/native code to > operate correctly. It discusses green threads explicitly. So, the spec > allows this, but notes (correctly) that most complex native code in the > world is unlikely to work when run on a JVM that uses green threads. Right, thank you. So, we are in a situation where the semantics of the environment in which JNI code runs are not well-defined, and we therefore have a choice whether we accommodate Jikes RVM's behaviour or not. I think we should. Although Jikes' behaviour is evil, IMO it's permissible to make Classpath work on it as long as it doesn't uglify the native code too much. I was concerned that we would be applying a band-aid to a broken JVM, but that doesn't seem to be so. Andrew.
