Pluggable bytecode verifiers (was RE: Summer of Code, something for Harmony?)
Bytecode verifiers appear to be one thing where the Harmony project could contribute some work in standardising interfaces. At the moment I know of two open source verifiers written in Java: BCEL (http://jakarta.apache.org/bcel/index.html, Apache Licence) and ASM (http://asm.objectweb.org/, BSD Licence) I believe that GCJ also has a verifier which it is (planning on?) sharing with Kaffe, but I haven't looked at that. The BCEL verifier can be used from the Verifier class http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/verifier/Verifier html The ASM verifier can be used from CheckClassAdapter: http://asm.objectweb.org/current/doc/javadoc/user/org/objectweb/asm/util /CheckClassAdapter.html From a short investigation, both verifiers have their advantages: for instance BCEL provides more complete verification, while ASM is faster and provides some JDK1.5 features. A more complete comparison can be found at http://mail-archives.apache.org/mod_mbox/jakarta-bcel-dev/200503.mbox/% [EMAIL PROTECTED] 3E and http://www.mail-archive.com/bcel-dev@jakarta.apache.org/msg00631.html It would appear to be a relatively simple task to create an interface that wrapped either of these verifiers. Presumably it would be no more work to integrate that common interface than it would be to integrate the native BCEL verifier. [snip] I posted a proposal in the wiki http://wiki.apache.org/general/SummerOfCode2005 It is about integrating the BCEL class verifier with one or more OS JVM (written in C or Java). JikesRVM has no current class verifier, neither jamvm or sableVM. As far as I know, the spec mandates to have class verification (I just read it in my JVM Spec (a bit old). I have been testing how feasible it is, and it looks the right size for someone interested in understanding this world, and something doable in a summer. [snip] 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.
Paper on integrating GCJ MMTk
Robin Garner sent me an interesting paper [1] he did which I've added to the FAQ [2]. It is about integrating JMTk/MMTk into GCJ, including some of the specific issues that they faced when combining the MMTk (written in Java) with GCJ (written in C) It may be useful reading for those interested in modular VMs Nick [1] http://www.cs.adelaide.edu.au/~wossa2004/HTML/07-garner-1.pdf [2] http://wiki.apache.org/harmony/TechnicalFAQ 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: FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/)
[snip] Does anyone have any benchmarks on such designs? As a hard-core real-time and device driver guy, I am rather skeptical that this is anything else but a conflict in requirements, runtime performance in execution speed versus interpretability and/or compilability of the runtime module. But then again, I've only been working with Java at all for less than four years :-) The discussion has been rehashed a lot of times. I'd like to see it put to rest (perhaps we need a technical FAQ?). See the end of this email for a brief answer anyway...* Should we do a FAQ on the Wiki or start a website (since now Harmony officially is in the incubator)? (Either way I'll volunteer to get this going) Great - start in the wiki, and we can bring out to website when it's filled out. Easier to start on wiki. geir Here's a start: http://wiki.apache.org/harmony/TechnicalFAQ 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
Can I make a plaintive plea for people to use sensible subject lines when starting new email threads rather than just replying to an existing one? Nick -Original Message- From: Bryce Leo [mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 May 2005 7:04 AM To: harmony-dev@incubator.apache.org Subject: Re: JIRA and SVN Any opinions on dumbing down the swing interface as to get a functional copy. As in, couldn't we find a way to let java use the gtk+ toolkit to build gui's though a swing implementation where they could have the functionality but only one look and feel. Or perhaps we could go the route of python and use the wxWidgets framework. Opinions? 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: [arch] The Third Way : C/C++ and Java and lets go forward
Geir Magnusson Jr. wrote: a) Respectfully petition JamVM for a one-time license grant of the codebase under the Apache License that we can start with. We would use this as our base kernel, refactoring out the modules that we decide on in II above, and working to implement those modules in whatever makes sense - Java or C. Robert brought up this issue on the list, so I have responded w/ a request on this list Just something to consider.. JamVM is optimized for size (and succeeds incredibly well at that), not necessarily completeness. For example, I don't think that it supports class loader unloading or soft/weak/phantom references (Robert please correct me if this is wrong). Those are non-trivial bits to have to design and write from scratch, and retro-fitting them into an existing VM could potential require significant rework. -Archie According to http://www.csc.uvic.ca/~csc586a/Ass1.pdf JamVm lacks a bytecode verifier, too. I suspect that would be easier to add than soft/weak/phantom references, though. 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.
FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/)
[snip] Does anyone have any benchmarks on such designs? As a hard-core real-time and device driver guy, I am rather skeptical that this is anything else but a conflict in requirements, runtime performance in execution speed versus interpretability and/or compilability of the runtime module. But then again, I've only been working with Java at all for less than four years :-) The discussion has been rehashed a lot of times. I'd like to see it put to rest (perhaps we need a technical FAQ?). See the end of this email for a brief answer anyway...* Should we do a FAQ on the Wiki or start a website (since now Harmony officially is in the incubator)? (Either way I'll volunteer to get this going) [snip] 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.
mudGE VM (was RE: Developing Harmony)
Try mudGE VM. The link is www.mudge.nl/java/ -Original Message- From: Rafal Lewczuk [mailto:[EMAIL PROTECTED] Sent: Friday, 20 May 2005 4:26 PM To: harmony-dev@incubator.apache.org Subject: Re: Developing Harmony Hi, On 5/19/05, Ian Darwin [EMAIL PROTECTED] wrote: MudgeVM is under an open license and should be looked at before you start committing stuff :-) I've tried googling and freshmeating for 'MudgeVM' but couldn't find it. Can I ask for links ? Thanks, rle 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: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Last Friday, I made the following proposal: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev /200505.mbox/[EMAIL PROTECTED] In the context of the current discussion I'd like to re-advocate that proposal. It is consistent with what Stefano has suggested. To summarize: 1. Leverage existing momentum by seeding the project with two existing VMs 2. Leverage existing work by focusing on modularity of major reusable components (including components from outside of the seed VMs). 3. Concurrently design new VM cores. Modularizing the seed VMs will provide the group with a great deal of insight into how new VM cores should be built. I say cores for three reasons: a) the cores will (by defn) be small, so with a modular framework, having multiple cores should be feasible, b) different cores can target different needs, c) we can explore different implementation strategies. --Steve +1 After looking through the code of Jikes I'm voting for this proposal (and the use of Jikes as a seed VM) because a) Jikes seems a fairly mature, and it appears somewhat modular already b) I am (much) more likely to be able to contribute to Jikes than a C-based VM I do have some concerns about the build process that Jikes currently has, but Steve has already spoken about addressing that. There are probably licence issues that would need resolving, too. This isn't meant as a negative vote against other VMs - Steve's proposal explicitly mentions working on other VMs in parrel. If people were going to work on JCVM (for instance) then I would imagine some enhancements could be shared, particularly to the parts of JCVM written in Java. It would also enable us to understand the interface requirements between parts of the VM better than most of us currently do. 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: [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: Testing - TCK, mauve, harmony's own test suite?
On the Pluto project (which has similar TCK requirements) the NDA hasn't really been a big issue. Some committers have signed and have access to it and some don't. We have our own set of test cases written based on the spec that committers use to verify their commits. We just make sure someone runs the TCK before doing a release (which I believe must be done on Apache owned hardware?). There are a few oddities with reporting errors, though, since you can't publish the actual test results, so you need to phrase your reports in terms of spec violations. I don't think you would be allowed to make the TCK available to people who haven't signed, so an external interface isn't allowed. I believe that on most Apache projects that require a TCK only a minority of committers have access to the TCK. That is certainly the case on Pluto and I believe that Tomcat works in a similar way. Nick -Original Message- From: Ricky Clarkson [mailto:[EMAIL PROTECTED] Sent: Tuesday, 17 May 2005 9:36 PM To: harmony-dev@incubator.apache.org Subject: Testing - TCK, mauve, harmony's own test suite? Hi, From informal chat in IRC, Davanum Srinivas (dims) said that each committer (not contributor) will sign an NDA (Non-Disclosure Agreement) with Sun to be able to use Sun's TCK (Technology Compatibility Kit), which is required for Harmony to be certified as Java. He also said that each contributor (not committer) will be able to test their patches against Harmony's own test cases and against mauve. This would mean, I think, that Harmony/mauve would duplicate Sun's TCK. First of all, it seems undesirable to duplicate Sun's TCK, and it seems difficult to make sure that this is legal. If all the Harmony committers sign a Sun NDA, will that mean that any test cases they write for Harmony or mauve will be suspect, on IP (Intellectual Property) grounds? Perhaps it would be better if at least one Harmony committer didn't sign the Sun NDA, then they wouldn't have anything to disclose. Further, it seems undesirable that a normal contributer (not committer) shouldn't be able to test their patches against the TCK, which is what you'd expect the committers to do before committing. Would it be possible/advisable to provide an interface to the TCK that a normal developer could use, without the Sun NDA (which I haven't read) being breached, e.g., a web page. Even if that was legal, technically it would be damn hard, because of security considerations, etc. Part of the 'etc' would be time; can part of the TCK be run, rather than the whole thing? I'd imagine the answer would be yes, but the method to do it might be laborious. Is the Sun NDA publically available, or is it subject to the Sun NDA? ;) Is the TCK's own licence under review at all, i.e., will it ever become free? While we're on a testing thread, what will Harmony's own test suite/cases use/look like? 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: Wiki: VM page
I've added a link to the J9 installation download: http://www-306.ibm.com/software/wireless/wctme/ Nick -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 4:08 PM To: harmony-dev@incubator.apache.org Subject: Wiki: VM page Mostly from comments on #harmony irc channel and browsing their sites, I've started a page to summarize all the JVMs that are being mentioned. For completeness sake, I've included the major commercial J2SE's. http://wiki.apache.org/harmony/JVM_Feature_Comparison I'm sure that I'm not alone on the list in being more interested in the class library than JVM, and a page like this will help us keep up with all of the VM discussions which naturally need to happen first/early. Along with the summary, I'd like to go further and try to describe the major open players, so will try to keep updating as I understand the special nature of each VM etc. Anyone have a url for J9 by the way? A quick bit of googling didn't get me there. Also, is there a different VM to J9 in the IBM JDK? Hen 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: A small documentation contribution
Yes: It's not a blog. It might make sense to maintain a FAQ there, though. Nick -Original Message- From: Ricky Clarkson [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 11:54 PM To: harmony-dev@incubator.apache.org Subject: Re: A small documentation contribution Any reason not to use the wiki - http://wiki.apache.org/harmony ? On 12/05/05, Nick Lothian [EMAIL PROTECTED] wrote: One of the big problems for newcomers to the Harmony project is discovering what has already been discussed. I suspect this could get worse as the project expands. I've started a blog to attempt to summarise the discussions on the mailing list and elsewhere: http://www.mackmo.com/apacheharmony/default/ The idea is that it will make it easy for people to come up to speed on issues. For instance, the next time someone suggests not implementing deprecated APIs they can be pointed at http://www.mackmo.com/apacheharmony/default/2005/05/11/Deprecated_APIs .h tml In the future some of this could get put in a formal FAQ sometime - in the mean time I'll try and keep it updated. Any suggestions for it are welcome. Nick [EMAIL PROTECTED] 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: Wishlist
In the only-partially-dreaming wishlist category: It would be really nice if (and make sense for) Sun open sourced Swing. That would: a) Help classpath along a lot b) Be a competitive move on Sun's part against IBM's SWT. -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Friday, 13 May 2005 2:53 AM To: harmony-dev@incubator.apache.org Subject: Wishlist In a lighter vein... - Wish we could resolve the licensing discussions and move on. - Wish one or more of the existing VM's consider donating to Apache. - Wish some of the BigCo's help with code and worker bees. - Wish we get to our first Hello World! soon. - Wish we end hunger/poverty/war all over the world (*) thanks, dims (*) Hey this is a wishlist. -- Davanum Srinivas - http://webservices.apache.org/~dims/ 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: JIT vs. WAT
[snip] GCJ begins to fall short where you wish to use Java's dynamic loading/linking capabilities. Classes must be loaded dynamically, garbage collected when they're no longer used, and integrated with the existing code. They must be bytecode-verified and sandboxed. I'm sure that someone who's really clever could make this all work under GCJ. But it essentially requires the glueing together of two very distinct compilation models --- the static and the dynamic. And it is unsatisfactory for many applications if the dynamically loaded code behaves differently --- for example, runs 3-5X slower because it's being interpreted. A fully dynamic fully JIT-based system seems simpler and more likely to work well for these applications. This is a really big deal. Most modern Java programs make extensive use of dynamic loading linking, and that usage is increasing. Recent releases of the Sun VM have put a lot of emphasis on speeding up the performance of reflection and this has been one of the big performance boosters in these VMs. [snip] 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: [
Hani is a smart guy and we would be wise to listen to what he is saying. He's a very active contributor to many (non-Apache) open source projects and has probably contributed more lines of open source code than the majority of people on this list. If that doesn't give him the right to comment then I'm not sure what does. It's true he could phrase them in a nicer(?!) way, though (but then it wouldn't be the Bile Blog). Greg Luck had a Not the Bile Blog for while that translated Hani's comments for the easily offended. See http://gregluck.com/blog/archives/2004/12/the_bileblog_wi.html To specifically address the issues Hani raised: Q) What is the clear need for an open source Java? A) There isn't a single good answer to this. My personal favourite is to allow it to be deeply integrated into the major Linux distributions, but other people may have different goal. Q) Is the approach of integrating multiple open source projects to build a J2SE implementation workable? A) This is an open question - there continue to be licensing issues to be worked out. Don't get offended - take it as a challenge and prove him wrong. -Original Message- From: FaeLLe [mailto:[EMAIL PROTECTED] Sent: Friday, 13 May 2005 11:46 AM To: harmony-dev@incubator.apache.org Subject: [ Can somebody comment on this guys claims, http://www.jroller.com/page/fate/20050507#death_to_apache Ps. warning: lot of flaming of our idealogies take place there but i would still like to see him shut up. -- www.FaeLLe.com http://www.FaeLLe.com 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: JIT vs. WAT
Nick Lothian wrote: GCJ begins to fall short where you wish to use Java's dynamic loading/linking capabilities. Classes must be loaded Most modern Java programs make extensive use of dynamic loading linking, and that usage is increasing. Recent releases of the Sun VM have put a lot of emphasis on speeding up the performance of reflection and this has been one of the big performance boosters in these VMs. IMHO both JITs and pre-compiling have their place.. it depends on the application whether one is definitely better than the other. Ideally, the design of harmony would allow for people to pursue both approaches and the two could coexist peacefully. E.g., it may be common for people to precompile all of the core classes, leaving everything else for runtime. This is where a well thought out design can lead to a very powerful and flexible system... there will be people who care about optimizing their particular scenario, and hopefully all such people can contribute to make the overall system more valuable to everyone, etc. Just rambling here.. imagine a code object contained executable machine code plus meta-data describing the assumptions behind any optimizations taken. Then the filesysytem could contain pre-compiled code objects that could be used, if appropriate, at runtime. New code objects would be created at runtime by the JIT, and optionally cached. Then the core VM becomes just a code object executor. It calls out to the JIT, the JIT cache, etc. on demand and provides any relevant runtime information, etc. JRockit does this, see: http://e-docs.bea.com/wljrockit/docs142/userguide/codecach.html 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: Against using Java to implement Java (Was: Java)
I assume that there is a project lead or leads associated with this coming from the Apache project, and they will make the determination of these initial matters. So speak up project lead(s). We are here. We are talking a lot, but not much is happening. Order us about. Assign work. Let's get our hands dirty. The likelihood is that there will be changes along the way anyhow. There almost always are, and developers dedicated to the project will simply have to adapt. That's not really how Apache works. If someone has a good idea they should implement it, or at least put forward a proposal for it. For instance, a proposal that has been implicit in this project since the start is: Apache Harmony should use the GNU Classpath class libraries Currently we are seeing a lot of discussion about that, particually WRT licencing. Another proposal is: The Apache Harmony VM should/should not be implemented in Java Implicit in that proposal is that a new VM will be written for this project. That isn't a decision that has been made yet, as other people are discussing creating an API that allows various exisitng VM implementations to be used, but it has brought some interesting discussion about the benefits of various approaches to light. To get to the point: If someone wants to write a new VM in Java then there are probably people on this list who will be interested in helping. However, there are probably other people who would think that decsion would be premature, since there is already a high quality Open Source VM written in Java (Jikes RVM) and the author/maintainer is active on this list. 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.
Proposal: A VM launcher
It seems people want something specific to work on. Here's an idea I had: Apache Harmony should develop a JVM launcher (java/java.exe) that uses a standard API (based on JNI_CreateJavaVM()) that will allow any VM to be used. Note that this is different to the alternatives command in Linux which makes it easy to switch between different launchers. This would be an important step forward because it would make it easier for developers to test on multiple VMs. It also has the benefit that of being a fairly (very!) small, self contained piece of work that isn't covered by any other cross platform project (AFAIK) but could be useful to all of them. The algorithm for VM selection could be as simple as user flags or it could use heuristics to analyze the machine it is running on and select an appropriate VM. The Sun VM currently has a similar mechanism that allows (for instance) the JRockit VM to be used from a Sun JRE installation by editing one config file and passing a command line argument: http://www.neward.net/ted/weblog/index.jsp?date=20030307 Some useful documentation links: Java JNI: http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/jniTOC.html Creating a VM using JNI: http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/invocation.html#wp159 56 Kaffe's launcher: http://www.kaffe.org/cgi-bin/viewcvs.cgi/kaffe/kaffe/kaffe/main.c?rev=HE ADcontent-type=text/vnd.viewcvs-markup Jsmooth: http://jsmooth.sourceforge.net/ Launch4J: http://launch4j.sourceforge.net/ Roll you own Java laucher: http://www.neward.net/ted/Papers/RollYourOwnJava/index.html (beware that this paper contains code from Sun's launcher - make sure you don't copy that) 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: I hope the JVM implements most using Java itself
constructive_interest [snip - I'm not qualified to answer the first question] This brings me to the second question. In my experience, writing in Java and writing in C (and therefore thinking in Java and thinking in C) tends to produce very different programs. The languages just lead you in different directions. Language shapes thought, you know. So, although one can argue that a Java program will ultimately be JITed (or WATed or whatever) to machine code, the program itself will not be written in the same way as a C program would be. Again, this is subjective and I expect people will not always agree with this. But I find that when I write C code, I'm thinking of CPU efficiency, changing strings in-place, and using pointers. Maybe *because* C is so painful, I tend to think of the simplest, most direct way to accomplish what is needed. However, when writing Java, I find that I think more of correct object abstraction for the problem at hand, code reuse, classes that maintain consistent state. I don't think twice of using a HashMap if it happens to be convinient, or that inheritance will cause extra indirections at runtime. To summarize (and to get to the question already) - the point is that language shapes thought. In other words, a program designed in Java will naturally tend to be slower then a program designed in C, simply because Java most naturally expresses slower designs then C does. And the question is - does this agree with anyone elses experiences? And if it does, is it a valid argument against using Java for the design and implementation of the VM? /constructive_interest Regards -dmitry I understand your logic, but I think it is flawed. Evidence shows that Java code running in modern VMs is coming increasingly close to hand-optimized solutions. One of the reasons often given for this is that a Java program often expresses the aim of the program at a higher level than an optimized C program, which gives the VM more room to optimize it. There are plenty of examples of optimized Java code becoming slower than non-optimized code when a new VM came out because the VM can do a better job optimizing than the programmer can. In the area of VMs benchmarks like http://www.shudo.net/jit/perf/ shows that the Jikes RVM (a pure Java VM) is very comptitive with other open source VMs. I believe that Mono (the Open Source .NET implementation) is written mostly in C#, and its performance is also very competitive. As Bob Griswold said earlier: The performance of the VM doesn't actually matter that much in a long-running application. It might make the code generation cycle faster (leading to faster start-up time, but not if it takes time to optimize the VM) or GC's to happen faster, but the VM code takes up typically less than 10% (usually far less than 10%) of the overall application performance time, so even if you double the performance of the VM, you will only get a small improvement in overall application performance. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mb ox/[EMAIL PROTECTED] 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: Harmony goals and priorities
Does either IBM or BEA own the rights to the class libraries that come with their JVMs? I was under the impression that they had simply licensed much of the code from Sun. I may be way off there, but it would be good to know for sure. Nick -Original Message- From: Bob Griswold [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 12:08 PM To: harmony-dev@incubator.apache.org Subject: Re: Harmony goals and priorities Karen: You and I have shared our thoughts and have seen eye to eye on this for a long time now. It's good to see this project getting started, and it's good to know that you are monitoring this and Red Hat will work to help integrate it deeply with Linux. I do still feel strongly that stability and commercial hardening are indispensable here. It would be great to get a BEA or IBM to donate their JVM's to this project - they are mature, pressure tested pieces of software that have had thousands of bugs shaken out of them. Shaking bugs out of JVM's is very different than shaking bugs out of Mozilla - or even Linux. JVM's do so many things indeterministically, no amount of testing can replace hundreds or thousands of years of cumulative customer production hardening. Bob On 5/11/05 6:18 PM, Karen Bennet [EMAIL PROTECTED] wrote: Bob, I share many of your thoughts on this topic and thank the Apache team for getting this project kickstarted. There have been some of us who have been attempting to get the commercial contribution path in place, but todate, different licensing, code integration problems, company strategic value-add direction, etc have prevented that path. I would like to highlight one of Red Hat's goal in working with this community project is to get a JRE deeply integrated within Linux. We also have another goal in mind for this project and that integration with SystemTap (Linux profiling project : http://sourceware.org/systemtap) which enables performance profiling through the JVM. Looking forward to this project moving out of the incubator stage. --- Bob Griswold [EMAIL PROTECTED] wrote: I ran the JRockit product group at BEA for the last 3.5 years from the time BEA first bought the Appeal team in Sweden until about 3 weeks ago (I¹m now at a small start-up doing some interesting things with AOP). I am excited about this project, but also a bit skeptical about it¹s chances for success. The overall goal of ³harmonizing² the JRE landscape is exactly what the industry needs it¹s something that BEA should have tried to do with JRockit long ago. The Java runtime is not something that any one company should own and rely on for competitive advantage it¹s a commodity/utility, and our ultimate enemy is the CLR. The Microsoft community has one managed runtime to target, while there are at least 3 credible JRE¹s in the Java world, each of them are different in hundreds of tiny ways despite passing a rigorous JCK. If harmonizing the JRE landscape is goal #1, then goal #2 is to have this JRE be open sourced so that it can be deeply integrated with Linux. M$FT is integrating the CLR deeply into Windows managed code will be a first class citizen. Linux should be the same. So, this project is exactly aimed at those two goals, so I am excited about it. In my experience trying to unseat the de facto standard JRE (HotSpot) for the last 3 years, any JRE that wants to be credible and used must satisfy a set of ³competitive qualifiers² just to be in the game, and must have at least some major ³competitive differentiators² to get people to make the switch: COMPETITIVE QUALIFIERS: 1. Must be 100% Java compatible. All of the services/API¹s/functionality people are talking about here are absolute minimum requirements. A JRE must pass the JCK 100% - any ³forking² will only serve to further fragment the non-M$FT world, and we can¹t afford for that to happen 2. Must be pressure tested/bullet proof. No one in the real world wants to debug their own JVM. You won¹t find a Wall Street bank, an airline reservation system, or a telco, adopting and using a new JRE unless and until it is solid, tested, and stable COMPETITIVE DIFFERENTIATORS: 1. Performance: At least as fast as HotSpot, but faster (on benchmarks that matter to the customer) is always better 2. Manageability/diagnostics: This is an area that JRockit has invested a great deal in the last few years. Memory leak detection, zero overhead profiling, fast debugging, real-time manageability/diagnostics, etc. 3. AOP: This is an area that has started to get a lot of attention lately. The whole idea of ³weaving² of code, or byte-code instrumentation in general, will go away entirely if the JVM handled this. The more commercial products we have out
RE: Harmony goals and priorities
I would have thought (perhaps naively) that the class libraries are the key issue here. There are a number of reasonably functional Open Source JVMs around. While they may not have quite the level of features as some of the commercial JVMs my impression is that they are probably reasonably close to what would be required to pass the VM part of the TCK. However, it appears to me that there is more work required in completing GNU Classpath - particularly in the Swing area. Of course, if BEA would like to Open Source JRockit I'm sure it would find a appreciative audience! My point is that the class libraries are the thing that will take the longest to complete. (Why is the J9 VM of such interest in particular? Isn't that just the VM IBM uses for it's J2ME implementations, and don't they have a separate, different JVM used in their J2SE implementation? Wouldn't that VM be of wider interest?) Nick -Original Message- From: Bob Griswold [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 12:37 PM To: harmony-dev@incubator.apache.org Subject: Re: Harmony goals and priorities Both IBM (in J9) and BEA (in JRockit) own 100% of the JVM - the virtual machine - that is just part of the JRE (Java Runtime Environment). Both J9 and JRockit are clean-room implementations of the virtual machines - this is where the biggest magic is in terms of performance, manageability, stability, etc. You are right to point out that the class libraries come from Sun, and while both IBM and BEA modify some of these libraries, they are derivative works of Sun's IP, so they can't open source those. Bob On 5/11/05 8:02 PM, Nick Lothian [EMAIL PROTECTED] wrote: Does either IBM or BEA own the rights to the class libraries that come with their JVMs? I was under the impression that they had simply licensed much of the code from Sun. I may be way off there, but it would be good to know for sure. Nick -Original Message- From: Bob Griswold [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 12:08 PM To: harmony-dev@incubator.apache.org Subject: Re: Harmony goals and priorities Karen: You and I have shared our thoughts and have seen eye to eye on this for a long time now. It's good to see this project getting started, and it's good to know that you are monitoring this and Red Hat will work to help integrate it deeply with Linux. I do still feel strongly that stability and commercial hardening are indispensable here. It would be great to get a BEA or IBM to donate their JVM's to this project - they are mature, pressure tested pieces of software that have had thousands of bugs shaken out of them. Shaking bugs out of JVM's is very different than shaking bugs out of Mozilla - or even Linux. JVM's do so many things indeterministically, no amount of testing can replace hundreds or thousands of years of cumulative customer production hardening. Bob On 5/11/05 6:18 PM, Karen Bennet [EMAIL PROTECTED] wrote: Bob, I share many of your thoughts on this topic and thank the Apache team for getting this project kickstarted. There have been some of us who have been attempting to get the commercial contribution path in place, but todate, different licensing, code integration problems, company strategic value-add direction, etc have prevented that path. I would like to highlight one of Red Hat's goal in working with this community project is to get a JRE deeply integrated within Linux. We also have another goal in mind for this project and that integration with SystemTap (Linux profiling project : http://sourceware.org/systemtap) which enables performance profiling through the JVM. Looking forward to this project moving out of the incubator stage. --- Bob Griswold [EMAIL PROTECTED] wrote: I ran the JRockit product group at BEA for the last 3.5 years from the time BEA first bought the Appeal team in Sweden until about 3 weeks ago (I¹m now at a small start-up doing some interesting things with AOP). I am excited about this project, but also a bit skeptical about it¹s chances for success. The overall goal of ³harmonizing² the JRE landscape is exactly what the industry needs it¹s something that BEA should have tried to do with JRockit long ago. The Java runtime is not something that any one company should own and rely on for competitive advantage it¹s a commodity/utility, and our ultimate enemy is the CLR. The Microsoft community has one managed runtime to target, while there are at least 3 credible JRE¹s in the Java world, each of them are different in hundreds of tiny ways despite passing a rigorous JCK. If harmonizing the JRE landscape is goal #1, then goal #2 is to have this JRE be open sourced so that it can be deeply integrated with Linux. M$FT
