Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
That being said...doing so in a portable and platform independent way is actually HARDER in Java than in C (and by C I mean C/C++/Objective-C...whatever). Read the Sable paper... you'll see what I mean :-) -Andy I'll certainly read the paper, but I find it difficult to believe that it is harder to implement portability with Java than with C++, given the latter's notorious holes in the spec that produce incompatibilities between different compilers and libraries using the same code. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
JIRA and SVN
JIRA: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740 SVN: http://svn.apache.org/repos/asf/incubator/harmony/ thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/
[dev-tools] was Re: Against using Java to implement Java (Was: Java)
If we are going to entertain writing most of the JVM in a type-safe language, we should also consider the proposed ECMA C++/CLI. From what I understand, it standardizes a form of type-safe C++. It has the promise of keeping both the Java and C camps happy. Not really. First, it is a Microsoft thing, tied in with .NET. Second, we don't want to have to depend on a .NET runtime to get a Java runtime. Third, never try to implement a large and complex existing project in a brand new technology. _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: timeframe for mid-level decissions
I've put some corrections in, so that its more understandable. Jakob Praher wrote: Geir Magnusson Jr. wrote: On May 19, 2005, at 5:24 AM, Jakob Praher wrote: I don't understand Take classpath project. It aims at working accross open vms. So you have to build a glue layer between what is intrinsic to the vm and what is expressable in plain java. Classpath has VM classes which are implemented by the different VMs (mostly public static and often native stuff), that gets called from within Classpath, so per VM you only have to reimplement the VM classes. It has pros and cons, if you proceed like this. For Classpath its the only way to meet the goal of implementing a whole runtime without knowing exact details of the VM. On the other hand projects like gcj, which have c++ abi for performance reason for most of the core classes (I mean the really core stuff) - they currently have libjava - where the whole classpath - but also would like to use the classpath java classes without importing them into libjava (for code management and stuff) where appropriate. To state it more clearly: GCJ has a copy of classpath in its own tree. In former classpath and gcj haven't worked that closely toghether. Most of the libjava classes are 1:1 copies of the classpath classes. But for some high performance classes / low level classes the gcj team rewrites them. This is a problem if they want to merge the whole classpath tree in. Why did I mention that: This is an example of the VMXxx classes to be to high level - a faster implementation can be done if using CNI (the GCJ native interface that uses C++ ABI). -- Jakob
Re: [dev-tools] was Re: Against using Java to implement Java (Was: Java)
So have to agree with Mark... Making a JVM in a .NET language this deserves a . LOL Sorry if i sound out of order had to do it :s On 5/19/05, Mark Brooks [EMAIL PROTECTED] wrote: If we are going to entertain writing most of the JVM in a type-safe language, we should also consider the proposed ECMA C++/CLI. From what I understand, it standardizes a form of type-safe C++. It has the promise of keeping both the Java and C camps happy. Not really. First, it is a Microsoft thing, tied in with .NET. Second, we don't want to have to depend on a .NET runtime to get a Java runtime. Third, never try to implement a large and complex existing project in a brand new technology. _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- www.FaeLLe.com http://www.FaeLLe.com
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
[Original Message] From: Stefano Mazzocchi [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 5/19/05 4:29:23 PM Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ Renaud BECHADE wrote: That being said...doing so in a portable and platform independent way is actually HARDER in Java than in C (and by C I mean C/C++/Objective-C...whatever). Read the Sable paper... you'll see what I mean :-) This is why I would like Harmony to have two VMs, one written in java and one written in C-or-friends: this would give us 1) the goal of making things modular enough to allow to swap things around and allow parallel development 2) create some internal (and friendly!) competition on speed and compliance :-) 3) attract two different pools of talents 4) allow compensation (easier to experiment in java than in C, harder to port java than C) Thoughts? -- Stefano. I think we should consider also another option that writing the JVM(s) in C and writing the class libraries in Java might be a nice compromise on portability. Use the system construction strength of 'C' and the JVM contect of Java for those two respective components. As I have seen everyone's comments on development language(s), I think we should continue to discuss it, but ultimately we need to use the development language(s) that make sense once some firm architectural design decisions have come together. At that point, we will have considered the ups and downs of languages and can have an intelligent place to decide, but we probably should decide what the scope(s) of action is(are) first, lest we get the proverbial [language] cart before the horse. Dan Lydick
Re: timeframe for mid-level decissions
On May 19, 2005, at 8:18 AM, Jakob Praher wrote: Geir Magnusson Jr. wrote: On May 19, 2005, at 5:24 AM, Jakob Praher wrote: - do we want to concentrate on the server side (jikes rvm would probably be fine for that) - for instance: no startup issues - do we want to build something that competes with sun j2se/ mono on the desktop side (gnome/redhat would be interested in that) Both of these are conventional expectations, and we can meet this via pluggability, right? Depends on the divergence of the 2 systems. If for instance you have 2 vms (eg. one in jave for server and one in c/c++ for client then IMHO it would be better to make two separate projects). These two vms wouldn't have much in common. That's sort of true. :) I'd agree that they would be separate efforts, but there's no reason why they couldn't be in the same Apache Harmony community. For example, look at the Apache Logging communty- there are alternate language implementations of the same functionality. I'd want to keep things close, as we do want to be able to share things. - do we want to have different projects for different tasks (is that effordable now - what is harmony then - a meta project?) Not now - right now, I think we stick close together until we start getting big. This *will* get big, but I think that the structure should be driven over time. This sounds promising :-). Sticking close together is what I'd like to see. Don't get too diverse now. Exactly. Lets be forced into it, rather than assuming and diluting now. - are the java specs anough for vm interoperability or should we add yet another interoperability layer between runtimes? I don't understand Take classpath project. It aims at working accross open vms. So you have to build a glue layer between what is intrinsic to the vm and what is expressable in plain java. Classpath has VM classes which are implemented by the different VMs (mostly public static and often native stuff), that gets called from within Classpath, so per VM you only have to reimplement the VM classes. It has pros and cons, if you proceed like this. For Classpath its the only way to meet the goal of implementing a whole runtime without knowing exact details of the VM. On the other hand projects like gcj, which have c++ abi for performance reason for most of the core classes (I mean the really core stuff) - they currently have libjava - where the whole classpath - but also would like to use the classpath java classes without importing them into libjava (for code management and stuff) where appropriate. Appropriate here means that the gcj project makes the trade of towards performance (at least that was the result of FOSDEMs discussion) if they have to decide. Oh, I see. You said between runtimes, so I had some other model, such as peer-peer runtime or something, which didn't make a whole lot of sense to me. - should we just be a forum for vm implementors and should we specify cross vm stuff (like the gnu.gcj.RawData class) in terms of enhancement requests? I think that we clearly want to implement, but it's not a bad place for enhancement, as long as we are clear that enhancement doesn't mean distortion of the standard, or extending. Ok. It's only for me to get an understanding of the projects identity. Yes thats probably true especially since we - as opposed to the closed source vms - don't have business interest in keeping secrets about inner layouts. Right - we're forming our identity as we do this. Patience :) I think the best projects (in that area) are those, that have a special goal and don't want to be all things to all people. I don't know which way harmony is going here. I think we have a goal, and I do think it's important that we hear about alternative paths to get there. I do agree that such discussions can't go on forever, and hence the pushing to start looking at some of the existing VMs (both in C and Java). I'm really hoping we can focus a little on that, how we can find ways to couple cleanly to GNU Classpath, etc. That's true. Perhaps I'm a little too eager - I have seen a lot of projects in the past. You might disagree here - but i think that this project is a bit different from other apache projects. Many things completly depend on the initial decisions. So I don't want to see all people waiting for some technical decision to take place and thus deadlock their efforts. At the same the possibily matrix is so huge that you can't take into account every project thats going on. So again: Make some decissions in the next months and go for that. Sure the project is in its infancy - I don't want to push too much. Right. Where do you stand on current VMs to look at or language? As I've posted, I think we should stick close to the indiviual target platforms (Unix,Win32,...) and build on stuff that works quite well (no java in java stuff). In recent time, I am a big fan of the LLVM project, since
Re: [arch] VM Candidate : JNode
On May 19, 2005, at 3:37 PM, Thorbjørn Ravn Andersen wrote: Geir Magnusson Jr. wrote: Can the VM be tweaked to work on standard OSs? Not immediately. I have raised the Harmony issue on the development forums, so I hope that they show interest in the issue here, and may be able to elaborate on whether JNode might be a suitable starting spot for Harmony. Please let us know how it goes. Thanks :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: JIRA and SVN
Thanks Dims. I'd again urge to not commit anything until we hash out some policies. This is an important issue. In the meantime, any comments on architectures of some of the VMs? I'm interest in having a balanced amount of upfront design that prevents us from preventing participation from unexpected places in the future... geir On May 19, 2005, at 11:14 AM, Davanum Srinivas wrote: JIRA: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740 SVN: http://svn.apache.org/repos/asf/incubator/harmony/ thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Developing Harmony
On May 19, 2005, at 2:38 PM, Rob Gonzalez wrote: - jc (written in C) - jikes rvm (written in java) Between those two I'm on the side of jc becuase it should run faster than jikes rvm, I don't know why it wouldn't. Though I don't know why Kaffe isn't on the list. AFAICT JC is the only real option on the table right now. - jc was donated under the apache license. - JikesRVM is CPL, so i don't believe it's automatically on the table without IBM's releasing a version under the apache license. - Kaffe is GPL and no one organization or person owns the copyright (as compared to GNU projects, for example), so it's basically impossible to re-license. since we're now officially in the incubator, can we check this into an apache SVN repository and get hacking at it? No. I think it's really in our best interest to sort out our commit policy before committing *any* code. (I still have fresh scars from Geronimo, due to process, rather than actual issues. But process can kill you...) Expect an email after I land tomorrow, 12:40 EDT :) Regarding the x-platform modularity goals; regardless of whether most of the VM itself is written in Java, C, or whatever, having a small bootloading VM layer that instantiates the rest of the VM -- again, a la JikesRVM -- is probably a good design decision and something that can be worked on immediately; not that I'm volunteering for that myself ;) . You mean a launcher? geir best, -Rob -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Developing Harmony
On May 19, 2005, at 5:26 PM, Ian Darwin wrote: AFAICT JC is the only real option on the table right now. - jc was donated under the apache license. since we're now officially in the incubator, can we check this into an apache SVN repository and get hacking at it? MudgeVM is under an open license and should be looked at before you start committing stuff :-) I'm looking at it. I'm trying to understand how it's architected. geir Ian -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [license] Contributions from tainted developers?
On May 19, 2005, at 5:25 PM, Rodrigo Kumpera wrote: Hi, What can someone that agreed to the SCSL contribute? I've agreed on the SCSL for the 1.4.2 JVM and I want to contribute to Harmony. I did a carefull reading of the license and in my layman's undestanding, I cannot contribute to anything that is convered by the 1.4.2 spec since it would need to be under the SCSL, but this also means that I can do 1.5 only stuff. The license has termination terms, but I have no clue if requesting it and destroying all copies of SCSL covered stuff would make me untainted. This is an important issue and recognize that it and related can have some far-reaching effects for us. There will be a post later about this. Please be patient and hang tight - we'll deal with it. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Developing Harmony
On 5/19/05, Ahmed Saad [EMAIL PROTECTED] wrote: Then, if the VM is written in Java it will be compiled to native code using, for example, gcj? or it will be compiled to byte code and will be interpreted by itself? One could interpret the VM code but it would be too slow for many. A better choice is to run the bytecode through a JIT or ahead of time compiler then execute the machine code. This binary image could be created at development time then distributed thus saving the end-user time and confusion. Yes, it is confusing. I am convinced that in the long term the JVM and the underlying OS will merge and that 90+ percent of the combination will be written in a type-safe language (either Java or C#). In the short term, I believe we should develop Harmony in C/C++ with a migration path to a type-safe language (either ECMA CLI based or Java.) I'm a little bit confused about this topic same goes here On 5/18/05, Juan Leyva Delgado [EMAIL PROTECTED] wrote: Then, if the VM is written in Java it will be compiled to native code using, for example, gcj? or it will be compiled to byte code and will be interpreted by itself? I'm a little bit confused about this topic - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Wednesday, May 18, 2005 4:46 PM Subject: Re: Developing Harmony Ozgur Akan wrote: JVM in Java will be the slower then Sun`s JVM. C or C++ is a better choice. You have to undertand that written in Java does *NOT* equate necessarely as will be run as interpreted bytecode. -- Stefano.
RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Why should it be so? I guess the platform dependent code emission code is err ... not platform independent anyway. Also, if the reference platform is for instance LLVM, or some other, off the shelf, low-level intermediate representation, then there is no more platform dependence to take care of at the JVM level (I suppose)... Andy is right: writing in Java *above* the JVM interface means you are creating bytecode and all the portability efforts were taken care for you by the JVM makers. writing in Java *below* the JVM interface means that you have to do, at some point, some native code transformations yourselfs, for every single different CPU architecture. This is true, but doesn't actually seem too hard. I'm looking at the arch section of the Jikes RVM (http://cvs.sourceforge.net/viewcvs.py/jikesrvm/rvm/src/vm/) and the two architectures there (intel PowerPC) certianly give a good starting point for other architectures. There appears to be an (unfinished) ARM backend available for it, too (http://www.cs.man.ac.uk/~jsinger/armrvm.html) Writing a JVM in a compilable higher language means that the compiler will do all that for you. No it doesn't (unless I'm missing something). It's true you will be able to compile your VM on other architectures, but you still need to write the code generator for those architectures yourself (ie, the bit that converts bytecode into native instructions). In a C-based JVM you'd need to write that in C whereas in Jikes RVM it is in Java. JCVM has a nice feature in this area in that it converts bytecode to C and then lets GCC compile that. That would appear to make it very portable, but it isn't the way most VMs work. (Ironicaly, the C genetation code in JC VM is written in Java - see http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/java/org/dellroad/jc/cge n/) Nick IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
Re: JIRA and SVN
- JCVM is maybe the VM as I would have written it : it's pure C, quite easy, and yet focus on bringing good speed. The interp loop is well optimized but not very defensive : that means that a hole in the bytecode loader verifier could lead to a forged bytecode exploit. It doesn't do JIT, and instead generate C from .class and then call GCC and dynload the binary : that requires a lot of libraries and might not be the approach Harmony want. Also, I'm a bit worried about C code portability : does it compile and run on Win32 using MS compiler for example ? I agree completely on that. After we strip away what we don't want, it looks like we'd be left with a relatively small, but capable framework to build upon. This is also to our benefit because newer programmers (which we clearly have a good number of, which is great to see) would be able to get up to speed relatively quickly. I believe that the more complex JikesRVM has some great concepts and that we could work with that through incorporating their ideas in the Harmony code. I mention the complexity because we have some new and relatively new programmers, and certainly a few new to VM's (as I would be one of them) and that the simpler code base would help out greatly in how quickly contributions could come in. This may or may not be an issue, if it's not then that's fine but I feel that a larger developer base is going to be needed even if it sacrifices the initial starting point for the project. compared to a good JIT written in pure C however. As a framework, it seems to contain several compilers, maybe focusing on one main implementation would be better. Strangely I think that the multiple compiler theory of Jikes is a great idea, it allows work to be divided up smoothly and seems to allow for a reasonable level of plugablity so if a group wanted to work on a re-implementation it wouldn't be terribly difficult. So my choice would be to go for either a stripped JCVM and add JIT to it (it should already work with interpreted, so the JIT can be written in Java or C) or for a stripped Jikes that - while keeping the framework architecture I think that this is a valid approach and gives a solid base while leaving flexibility for growth. -- ~Bryce Leo --Veritas Vos Liberabis--
RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
$B!d(BThis is why I would like Harmony to have two VMs, one written in java $B!d(Band one written in C-or-friends: this would give us $B!d(B $B!d(B 1) the goal of making things modular enough to allow to swap things $B!d(Baround and allow parallel development $B!d(B $B!d(B 2) create some internal (and friendly!) competition on speed and $B!d(Bcompliance :-) $B!d(B $B!d(B 3) attract two different pools of talents $B!d(B $B!d(B 4) allow compensation (easier to experiment in java than in C, harder $B!d(Bto port java than C) $B!d(B $B!d(BThoughts? (B (BHaving a plugin-based JVM based on a VM that already works (or even /ANY/ (BJVM if we suppose we do enough bytecode engineering[1] and limit ourselves (Bto minimum assertions on the runtime - say we only use JNI Java debugger (Binterface reflection to link bytecode with JIT generated code) could do (Bthat, with the added benefit we have a working system NOW (including the (Blibraries for java 5, that are quite a big bunch of work in themselves, and (Bthe packaging effort). I think this is compatible with the use of an LLVM (Bbased solution too (for instance llvi calls gcj or another VM with the (Badequate function pointers so that gcj can in turn call the LLVM-based VM (Bplugin. (B (Bs/gcj/other vm/. My point is that gcj is working everywhere, really, even (Bobscure chips, and can potentially execute java5 bytecode (with the adequate (Bjava 5 bytecode - java normal bytecode + additional meta information in (Bsome format if required), NOW. (B (BThat makes 2 VMs, one in C/C++ (bootstrap VM, a hacked version of an (Bexisting one) and one in java (the JIT plugin), and also a common runtime to (Bdevelop (which in itself is resource-greedy) (B (BAnother point that is unrelated, but what about the "packaging" of the VM? (BDo we plan to release it with say Eclipse + Server (JSF + IDE + object DB or (BO/R mapping + HSQL DB)? (IMHO this is good way to legitimate it) (B (B[1] ex: the AOP techniques used in JAC enable transparent distributed (Bdeployment, such as for instance A calls B on machine x but in fact B is (Bworking on machine y (and except from the AOP system, x has a jar of A+B, or (Ban empty shell of B, where a calls B the "usual way") (B (B[Renaud BECHADE] RB
FW: timeframe for mid-level decissions
(B $B!d(BFrom the llvm web site: "LLVM does not currently support garbage $B!d(Bcollection of multi-threaded programs or GC-safe points other than $B!d(Bfunction calls, but these will be added in the future as there is $B!d(Binterest." I would imagine that's quite a lot of work. (B (BOuch, but I suppose this is less work than say write form scratch an (Boptimizing JIT for 4 or 5 different architectures (x86, AMD64, powerpc32bit, (Bpowerpc64bit, sparc, arm, etc.) (B (BRB (B (B-Original Message- (BFrom: David Griffiths [mailto:[EMAIL PROTECTED] (BSent: Thursday, May 19, 2005 11:33 PM (BTo: harmony-dev@incubator.apache.org (BSubject: Re: timeframe for mid-level decissions (B (BFrom the llvm web site: "LLVM does not currently support garbage (Bcollection of multi-threaded programs or GC-safe points other than (Bfunction calls, but these will be added in the future as there is (Binterest." I would imagine that's quite a lot of work. (B (BCheers, (B (BDave
RE: timeframe for mid-level decissions
(BI like it. (B $B!d(B* Work together with the GCJ people to build a really fast AOT-compiler $B!d(Bthat also works with LLVM based Execution Engine (B (BI which case we theoretically have a JIT at supposedly low cost... (B(translating bytecode to bytecode /without having to optimize it/ is great) (BI still like the plugin way this could be implemented. (one can (Btheoretically call LLVM and get called by LLVM) (BThere would still be a lot of work needed for the java5 apis, anyway. (B (BRB (B $B!
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
The problem of Java written JVM/JIT isn't one of performance. You can theoretically achieve the same performance (although I'm not 100% convinced, I'm partially there) It is reasonable to model the performance of a Java runtime in several aspects, especially throughput and interactivity (start-up time). JIT (and JVM) written in Java can achieve the same throughput as one written in C/C++/etc. But good start-up time / interactivity are more difficult to achieve and have to be elaborated. Part of a runtime written in Java has to be interpreted, or compiled before executed. Throughput is sacrificed when interpreted and interactivity is sacrificed when compiled. Another possible disadvantage, which might not be discussed, is reflective nature of Java-written JVM. This has been appealed as one of strong points in this list so far as removing boundary of languages. But we have to consider maintenance and debugging of the runtime. Java-written JIT is compiled by itself eventually. In the case, debugging will become pretty hard. Of course, such a runtime will have another interpreter or a baseline compiler (written in C/C++?) and Java-written JIT can be debugged exhaustively. But such a reflective nature certainly makee debugging harder. I myself do not have any experience on development of Java-written JIT and then I am not very sure how it makes maintainance and debugging harder. There have been a few Java-written JIT, Jikes RVM and OpenJIT and we may be able to have input from the developers of them if we hope. Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
I think jikesrvm can be executed from another JVM, this should make debugging easy. On 5/19/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The problem of Java written JVM/JIT isn't one of performance. You can theoretically achieve the same performance (although I'm not 100% convinced, I'm partially there) It is reasonable to model the performance of a Java runtime in several aspects, especially throughput and interactivity (start-up time). JIT (and JVM) written in Java can achieve the same throughput as one written in C/C++/etc. But good start-up time / interactivity are more difficult to achieve and have to be elaborated. Part of a runtime written in Java has to be interpreted, or compiled before executed. Throughput is sacrificed when interpreted and interactivity is sacrificed when compiled. Another possible disadvantage, which might not be discussed, is reflective nature of Java-written JVM. This has been appealed as one of strong points in this list so far as removing boundary of languages. But we have to consider maintenance and debugging of the runtime. Java-written JIT is compiled by itself eventually. In the case, debugging will become pretty hard. Of course, such a runtime will have another interpreter or a baseline compiler (written in C/C++?) and Java-written JIT can be debugged exhaustively. But such a reflective nature certainly makee debugging harder. I myself do not have any experience on development of Java-written JIT and then I am not very sure how it makes maintainance and debugging harder. There have been a few Java-written JIT, Jikes RVM and OpenJIT and we may be able to have input from the developers of them if we hope. Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Nick Lothian wrote: Why should it be so? I guess the platform dependent code emission code is err ... not platform independent anyway. Also, if the reference platform is for instance LLVM, or some other, off the shelf, low-level intermediate representation, then there is no more platform dependence to take care of at the JVM level (I suppose)... Andy is right: writing in Java *above* the JVM interface means you are creating bytecode and all the portability efforts were taken care for you by the JVM makers. writing in Java *below* the JVM interface means that you have to do, at some point, some native code transformations yourselfs, for every single different CPU architecture. This is true, but doesn't actually seem too hard. I'm looking at the arch section of the Jikes RVM (http://cvs.sourceforge.net/viewcvs.py/jikesrvm/rvm/src/vm/) and the two architectures there (intel PowerPC) certianly give a good starting point for other architectures. There appears to be an (unfinished) ARM backend available for it, too (http://www.cs.man.ac.uk/~jsinger/armrvm.html) Ok. I admit I never looked into that part myself so I can't tell you how hard it is to port a java VM onto another CPU architecture. Writing a JVM in a compilable higher language means that the compiler will do all that for you. No it doesn't (unless I'm missing something). It's true you will be able to compile your VM on other architectures, but you still need to write the code generator for those architectures yourself (ie, the bit that converts bytecode into native instructions). In a C-based JVM you'd need to write that in C whereas in Jikes RVM it is in Java. D'oh, you're absolutely right! JCVM has a nice feature in this area in that it converts bytecode to C and then lets GCC compile that. That would appear to make it very portable, but it isn't the way most VMs work. (Ironicaly, the C genetation code in JC VM is written in Java - see http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/java/org/dellroad/jc/cge n/) Hmmm, interesting... I wonder if we could hook directly into the compiler intermediate representation instead of having to write a big string using C syntax and fire a parser on it. Does anybody know if GCC allows such a thing? Keep in mind I know squad about GCC and friends. -- Stefano, who should really do his homework some day.
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Sure it does, we would be writing just a front-end. Which in case is not an option for Harmony, since such code must be GPL. Does anybody know if GCC allows such a thing? Keep in mind I know squad about GCC and friends. -- Stefano, who should really do his homework some day.
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Andy is right: Wow! This is why I would like Harmony to have two VMs, one written in java and one written in C-or-friends: this would give us 1) the goal of making things modular enough to allow to swap things around and allow parallel development 2) create some internal (and friendly!) competition on speed and compliance :-) 3) attract two different pools of talents 4) allow compensation (easier to experiment in java than in C, harder to port java than C) Thoughts? Yes. -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
MIT compiler course
So for those who are not compiler buffs but wish to be, this MIT online courseware stuff can be helpful. Also buy the books especially the Tiger one for an introthe more advanced books by Steven Muchnick are a much more challenging read and the fortran hurts my head...though the theory is helpful and there are some good explanations of the different chip arcitecture. I'm working up the stomach to actually READ them cover to cover...though I'm not looking forward to becoming a fortran expert... course link: http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-035Computer-Language-EngineeringFall2002/CourseHome/index.htm There is other relevant MIT courseware but you can search for that yourself :-) Note that you should use the search and not rely on the categorical stuff because somehow not everything that is searchable seems to be locatable via categorical search. Unfortunately its just lecture notes and projects, etc. It'd be really cool if they had some kinda audio or video or something...but then I guess it'd be MIT on the cheap. -Andy -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
