W liście z pon, 12-08-2002, godz. 21:22, Adam Heath pisze: > So, what about kaffe? What about gcj? Why are you saying that sable is > better than these others? Below I am forwarding parts of a mail from sablevm author, Etienne M. Gagnon [...] > > I also looked at porting abilities - I think that one day per arch > > may be sufficient to get it working. Let's count - two weeks and we > > have all Debian's arches working! ;-) > > I've seen some of the follow up comments to your post. Regarding > 'gij': by looking very quickly at its interpreter.cc source file, I > detected important race conditions (for multithreaded apps). Part of > my Ph.D. thesis will discuss how to implement a Java bytecode > threaded-interpreter without causing race condition (and without over > synchronizing). > > Also, SableVM implements the invocation interface, and has clean > support for native code through the "standard" JNI interface. Now, > GIJ's people main objection to JNI (instead of their custom CNI) is > that it is slow. Yet, even though they have potential race > conditions, and their use of CNI, SableVM is at least 2X faster than > GIJ on all benchmarks I've tested. > > This goes without talking about the limitations of CNI. It is > *incompatible* with: moving collectors, bidirectional object layout, > long running CNI code (because a request for GC would wait > indefinitely and possibly lockup the VM). etc. > > I have no difficulty whatsoever to compare SableVM with GIJ. SableVM > supports: "moving collectors", "moving/growing stacks", long > running/sleeping JNI code, precise garbage collection, no race > conditions in the core interpreter engine (as far as I know), precise > exceptions with line numbers even in presence of an inlined-threaded > interpreter, its "switch0threaded" engine is written in pure > ISO/POSIX, the only extention used for direct/inline-threading is that > of "labels-as-values" which presumably can be emulated on non-GCC > compilers using "inline assembly", etc. [...] > > 3. having some optional JIT (even for x86) - I saw some discussion about > > having JIT written in Java and itegrated with sable - is anyone working > > on it? > > Starting in the fall, yes. There's the whole Sable project (which has > brought the Soot bytecode analysis framework to the world) behind > SableVM. This means at least 3 faculty-researcher and their graduate > and undergradute students. [...] > I am incidently teaching a graduate course this Fall. Students will > have the option of making SableVM related course projects. Of course, > a JIT is bigger that one course project, but is "speed" the only > important thing? Isn't robustness (no race conditions, memory > corruption, etc) first on the list? It seems many JVM implementors > put more energy into "speed" rather than "robustness". SableVM is the > other way around, robustness (with acceptable speed) goes first. > > The current version has ample room for for improvement (e.g. managing > thread-local heaps to reduce the amount of synchronization; currently > every instance creation (NEW) causes "fat" pthread_mutex_lock > synchronization). Even thoug, it achieves a comparable performance to > that of JDK1.4 "java -Xint" interpreter (e.g. fatser on some > benchmarks, slower on others). Now, everyone knows that Sun's > interpreter has sections written in assembly (I can't assert so, not > having seen the source code, at it would conflict with clean-room > status). It is >2X faster than JIG without taking shortcuts (CNI, > missing synchro, no handling of runaway native code, etc), and has, in > my "humble" opinion, much more readable source code. It is sometime > 10X faster than Kaffe's "intrp" engine (which is heavily used by > reasearchers that do not want to get into modifying a compiler to test > their ideas). It is far more easily portable than the JikesRVM, even > though the later is written in Java, because you don't have to modify > 3 compilers(!) to port it to a new platform. > > Sorry, I had to get it out;-) [...] > Etienne > > -- > Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/
Attachment:
signature.asc
Description: PGP signature