Archie Cobbs wrote: > That makes sense.. i.e., if you want to make it into something of a > research project to define the best possible Java/VM API then I'd be > interested in that as well. Of course this will take more work.
I think not. Internally, SableVM has a pretty modular stucture. All we've traditionally done was to add some hook code for Classpath, not the other way around. In other words, SableVM has never been designed around Classpath's VMI (which actually was a moving target when I started developing SableVM). So, since we can't use Classpath's code, then I don't see how it would really help to closely stick to a Classpath design. Maybe I will end up with an identical design, yet, my feeling is that many little things might be different in the new solution. > First > of course is defining what the goals and priorities are (if your goal > were to do it quickly, then re-using the existing Classpath API would > be the best option imho). It has always been the philosophy of SableVM project to take the time to design and implement things as best as we could, instead of taking the fastest shortcut. I know, many are anxious to see everything working together "yesterday". If anoyone wants to do that, please feel free to contribute the code that does it. Personally, I would much like to see a well defined and correctly implemented VMI, that correctly takes care of tricky class loading cases, etc. > - Class loading. Can maintenance of initialized and/or derived types > trees be done in Java? Loading constraints? Etc. Mostly in Java, of course. > - VM private data structures: could more of these be stored in > byte[] arrays, so that Java code can just pass the byte[] array > to native code where appropriate? Pointers must be passed around Java/VM in architecture independent way. Byte arrays are one solution for this. > - Class initialization: SableVM already does this in Java I think. Of course, it does. > - Threads This one's tricky. :-) > - Exceptions SableVM has a mix of Java and VM code here. > - GC: any Java possibilities here? A C compiler does a very good job at optimizing the garbage collector. Why write this in slower Java code? I have trouble seeing even an adaptive system offering any significant improvement for such code. Maybe I'm wrong. I'll let the JikesRVM people school me here. [Hmmm... Dunno if HotSpot server does it in C or Java... Is there any research paper that tells us about this?] > - Bytecode verification In Java, of course! Yet, I invite you to read my Ph.D. thesis for tricks on calculating GC maps without performing full verification. [Necessary to do in C, because of bootstrap]. > The more you "push down" the more it starts to get into the "VM written > in Java" concept a la Jikes RVM. I have no religious beliefs in either direction. I say: do it where it makes the most sense. Note how JikesRVM is much less "portable" than SableVM, even if it's written in Java. Yet, see how faster it is, even if it's written in Java. (DREAM WARNING) Personally, I wouldn't mind seeing a hybrid SableVM/JikesRVM where bootstrap happens in C (no complex platform dependent image generation process), but adaptive compilation happens in Java... > Another idea: the VM API is just POSIX (or some subset), and you have > some way to manipulate (pack/unpack) C types via Java. Why would we do in Java what is best done in C? System calls are better done in C. C data structures are better stored in malloc()'d memory rather than in a moving heap... (I know; there's a lot of subjectivity on what is "best"). Etienne -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
