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: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
a! we dont need any mess right up now so leave it now ;) On 5/22/05, Ben Laurie [EMAIL PROTECTED] wrote: Stefano Mazzocchi wrote: People, as you probably already understand, being focused on web stuff, Apache attracted pools of people (ourselves mentors included) that know very very little about compilers and VMs. Speak for yourself - I've written compilers and VMs, though not for Java and quite a long time ago now. It's very educational, you should try it someday. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff -- Usman Bashir
Re: Other interesting papers and research
Other interesting things that can be achieved are some sorts of high performance tunning aspects, which are very interesting, and using gcc power might be more interesting than redoing it from scratch, either, at the begining of current project, or maybe forever. An adequate bundle of gcc and harmony might produce a JIT/WAT java/bytecode compilation. Moreover, the compilation parameters might be tuneable by the JVM administrator and choose between compilation speed, compilation performance, memory footprint, etc. Appart from code-reusing, there is also an adequate sort of abstraction that is good here. and concentrating on this, we avoid discussing machine level details as we all agree that GCC is portable, performant and adequate. Summing up, I support the idea of a java/bytecode to C compiler that can be bundled with gcc. As stated we would gain portability and we can use all facilities provided by gcc. Ariel Archie Cobbs wrote: [EMAIL PROTECTED] wrote: The approach of using C Compiler generated code rather than writing a full compiler appeals to me: http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf I am curious on how well the approach performs compared to existing JITs. I'm admittedly biased, but the approach of using the C compiler has some good benefits, mainly in portability. This is especially true for architectures like x86 that have a complicated instruction set, where optmization is a subtle art. Though JC uses the C compiler as a WAT instead of a JIT, it is very portable (to any architecture that GCC targets) as a result. To the extent that portability is a goal, this might make sense as an approach to take, at least initially. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
RE: Other interesting papers and research
＞Summing up, I support the idea of a java/bytecode to C compiler that can ＞be bundled with gcc. As stated we would gain portability and we can use ＞all facilities provided by gcc. To me it sounds a bit like gcj... In order to use a low level bytecode as an intermediate representation, LLVM bytecode (which can be emitted by a modified version of gcc [may be useful for rapid prototyping]) could be a realization of your ideas, IMHO. Another way I see it would be to use a simplified version of Java bytecode to represent low-level instructions (as the Squeak Smalltalk VM works: only static methods and a restricted class set is supported, this way it is possible to run the VM in itself, and also to machine-generate C code from the VM sources. In modern days we might consider generating LLVM bytecode - or simply use gcj! For this kind of architecture, for instance [1]) Regards, RB [1] not sure about the implications in terms of speed, though. In my point of view it is better, anyway, to have a working system first and then hook bestial optimizations latter [once the execution model is simple enough or rather close enough to a reasonable machine abstraction this might be somewhat easier/less difficult] PS: I am favorable to use a "java in java" VM as a plugin to such a system. (or rather, have a "stock" VM with fast uptimes as bootstrap and then a "very optimizing" plugin, which does not need to tackle with anything but code generation itself - if this is really possible) -Original Message- From: Ariel Sabiguero Yawelak [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: Other interesting papers and research Other interesting things that can be achieved are some sorts of high performance "tunning" aspects, which are very interesting, and using gcc power might be more interesting than redoing it from scratch, either, at the begining of current project, or maybe forever. An adequate "bundle" of gcc and harmony might produce a JIT/WAT java/bytecode compilation. Moreover, the compilation parameters might be "tuneable" by the JVM administrator and choose between compilation speed, compilation performance, memory footprint, etc. Appart from code-reusing, there is also an adequate sort of abstraction that is good here. and concentrating on this, we avoid discussing machine level details as we all agree that GCC is portable, performant and adequate. Summing up, I support the idea of a java/bytecode to C compiler that can be bundled with gcc. As stated we would gain portability and we can use all facilities provided by gcc. Ariel Archie Cobbs wrote: [EMAIL PROTECTED] wrote: The approach of using C Compiler generated code rather than writing a full compiler appeals to me: http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf I am curious on how well the approach performs compared to existing JITs. I'm admittedly biased, but the approach of using the C compiler has some good benefits, mainly in portability. This is especially true for architectures like x86 that have a complicated instruction set, where optmization is a subtle art. Though JC uses the C compiler as a WAT instead of a JIT, it is very portable (to any architecture that GCC targets) as a result. To the extent that portability is a goal, this might make sense as an approach to take, at least initially. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Java bytecode metrics?
I've been wondering about the cost of adding gc points to every backwards branch in LLVM (as would need to be done to make it multithreaded). A paper here http://research.sun.com/techrep/1998/abstract-70.html suggests the cost is around 5% of total running time (compared to code patching). What I was wondering was, does anyone know of any code metrics for large collections of Java bytecode? Eg what is the average number of bytecodes in a method, what is the average ratio of backward branches per bytecode and so on. Is code patching a technique that has been widely employed in JIT compilers? (I liked the idea of using an access to a write-protected page to reduce the cost of polling!) Cheers, Dave
Re: Threading
On May 23, 2005, at 1:05 AM, Weldon Washburn wrote: Interestingly Sun Solaris 9 dropped M:N threads. From http://www.sun.com/software/whitepapers/solaris9/multithread.pdf, One such innovation is the move away from the original MxN model to a 1:1 implementation. Again, this is not to say that a good implementation of the MxN model is impossible, but simply that a good 1:1 implementation is probably sufficient. Long term, I suspect that the thread management code that sits inside today's JVM and the thread scheduler that sits inside today's standard OS will merge. Generic LinWin preemptive thread scheduling that suspends a thread at an arbitrary location is not compatible with the GC's need to have threads suspended at GC safepoints. While this may not be a big deal on today's 1-4 way CPU systems, its likely to become a bottleneck on tomorrow's multicore boxes. So how do we examine this today - is there any way to take advantage of OS threading at all? How do you do thread management now? Most likely the merged/unified thread scheduler will be written in a type-safe language such as Java. The interesting long term question is when will the entire JVM be merge into the underlying OS? And when will the resultant JVM/OS be re-written in a type-safe language? I suspect a modular Harmony that allows a mix and match of components in ansi C (popular with the OS crowd) and components written in Java/C# will be very useful. I've been thinking the same. I was nudged in the direction of compromise, that realistically, we'll be wanting to use pieces written in Java. And I'm still going through ANSI C anti-withdrawal. I was looking at some C code (JamVM?) and the whole thing gave me the shakes. :) geir On 5/22/05, Rodrigo Kumpera [EMAIL PROTECTED] wrote: Green threads have a lot of problems that are hard to solve. You have to deal with blocking function, interupts, syscall restarts, blocking native code, etc... JikesRVM handles that gracefully? My impression is that everyone is dropping this M:N model because of implementation issues. BEA dropped it on jrockit. IBM was developing such system for posix threads in linux, but a simple 1:1 that solved some scalability problems in the kernel was choosen. On 5/22/05, Steve Blackburn [EMAIL PROTECTED] wrote: The Jikes RVM experience is kind of interesting... From the outset, one of the key goals of the project was to achieve much greater levels of scalability than the commercial VMs could deliver (BTW, the project was then known as Jalapeno). The design decision was to use a multiplexed threading model, where the VM scheduled its own green threads on top of posix threads, and multiple posix threads were supported. One view of this was that it was pointless to have more than one posix thread per physical CPU (since multiple posix threads would only have to time slice anyway). Under that world view, the JVM might be run on a 64-way SMP with 64 kernel threads onto which the user threads were mapped. This resulted in a highly scalable system: one of the first big achievements of the project (many years ago now) was enormously better scalability than the commercial VMs on very large SMP boxes. I was discussing this recently and the view was put that really this level of scalability was probably not worth the various sacrifices associated with the approach (our load balancing leaves something to be desired, for example). So as far as I know, most VMs these days just rely on posix style threads. Of course in that case your scalability will largely depend on your underlying kernel threads implementation. As a side note, I am working on a project with MITRE right now where we're implementing coroutine support in Jikes RVM so we can support massive numbers of coroutines (they're using this to run large scale scale simulations). We've got the system pretty much working and can support 10 of these very light weight threads. This has been demoed at MITRE and far outscales the commercial VMs. We achieve it with a simple variation of cactus stacks. We expect that once completed, the MITRE work will be contributed back to Jikes RVM. Incidentally, this is a good example of where James Gosling misses the point a little: MITRE got involved in Jikes RVM not because it is better than the Sun VM, but because it was OSS which meant they could fix a limitation (and redistribute the fix) that they observed in the commercial and non-commercial VMs alike. --Steve -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: JIRA and SVN
On May 21, 2005, at 12:11 AM, [EMAIL PROTECTED] wrote: As I understand it there is no TCK coverage for Swing I'm not so sure w/ the TCK for J2SE 5. (which will probably make that a long trip frankly) and well AWT is what AWT is. It is unlikely that we'll achieve a satisfactory swing implementation for some time (though there are approaches that I've seen for automating unit tests for it). One fantasy is that Sun might be so good as to donate an implementation, so that we can be sure that we have something that is compatible for our users. Think happy thoughts on this one... Secondly, Java applications and applets more or less suck. There are exceptions, I agree, I know, etc. However, the approaches to GUI in the product called Java are simply not competitive (and I've no real solid knowlege of SWT, but I've programmed enough with other toolkits to know what I'm missing). So for an achievable simplicity initial focus should be on #1 and #3. Obviously we'll need to cover the rest eventually. Yep geir -Andy Tom Tromey wrote: Geir == Geir Magnusson [EMAIL PROTECTED] writes: Geir In the meantime, any comments on architectures of some of the VMs? Geir I'm interest in having a balanced amount of upfront design that Geir prevents us from preventing participation from unexpected places in Geir the future... This is too vague -- we don't know much about the unexpected. Plus, in most cases, the core part of the VM is simply not very important. There just isn't much code there -- JamVM is 20KLOC, anybody could comfortably rewrite this. Instead I think Harmony should look at 2, and possibly 3, use cases: 1. Server use, e.g., some J2EE thing. 2. Desktop / applet use. 3. Embedded use (maybe). For 1, the execution engine and GC is really crucial. This is an area where hotspot-like dynamic recompilation implementations shine, IMO. For 2, again IMO, a gcj-like shared library approach is probably more useful. This is especially true if you expect to run more than one program using a given library, since in this case you are talking about controlling memory costs of the user environment as a whole. For 3 ... embedded covers a lot of ground, but I wanted to emphasize size-critical applications. In this arena you sometimes see folks who care more about size than performance. This affects choice of execution engine. I think it is possible to work well in all 3 environments with a single VM source base (though perhaps with different compilations of it). I think one way to do this would be an LLVM-based approach. This would require LLVM improvements, but let's be very clear about this -- *any* approach we take to get to #1 and #2 is going to require a lot of compiler hacking. First, JITs have to be upgraded over time. Second, even with JikesRVM I think we're talking about at least writing new ports and an infrastructure for debuggers. One nice thing about the LLVM approach is that, hopefully, we could leverage other people's work. This is one reason gcj has been as widely ported as it is; the core gcj developers hardly ever do any architecture-specific work but instead we just inherit it from GCC. Tom . -- 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. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/)
great. thanks. Lets make sure we keep it up to date geir On May 23, 2005, at 2:39 AM, Nick Lothian wrote: [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. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Other interesting papers and research
From: Steve Blackburn [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The approach of using C Compiler generated code rather than writing a full compiler appeals to me: http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf I am curious on how well the approach performs compared to existing JITs. They automatically build themselves simple JIT backends (by extracting fragments produced by the ahead of time compiler). This sounds like a great way to achieve portability while achiving better performance than a conventional interpreter. I guess it's a bit better or just comparable with a good interpreter. In 1998, I have written such a JIT compiler concatinate code fragments generated by GCC for each JVM instruction. Unfortunately, the JIT was slightly slower than an interpreter in Sun's Classic VM. The interpreter was written in x86 assembly language and implements dynamic stack caching with 2 registers and 3 states. It performs much better than the previous interpreter written in C. Then I rewrote the JIT. I am not very sure which is better for us, having a portable and so-so baseline compiler or a good interpreter which is possibly less portable than the compiler. There will be a trade off between memory consumption, portability and so on. Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
Re: Threading
On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 23, 2005, at 1:05 AM, Weldon Washburn wrote: Interestingly Sun Solaris 9 dropped M:N threads. From http://www.sun.com/software/whitepapers/solaris9/multithread.pdf, One such innovation is the move away from the original MxN model to a 1:1 implementation. Again, this is not to say that a good implementation of the MxN model is impossible, but simply that a good 1:1 implementation is probably sufficient. Long term, I suspect that the thread management code that sits inside today's JVM and the thread scheduler that sits inside today's standard OS will merge. Generic LinWin preemptive thread scheduling that suspends a thread at an arbitrary location is not compatible with the GC's need to have threads suspended at GC safepoints. While this may not be a big deal on today's 1-4 way CPU systems, its likely to become a bottleneck on tomorrow's multicore boxes. So how do we examine this today - is there any way to take advantage of OS threading at all? How do you do thread management now? I can only speak for how ORP JVM was designed. THe short answer is, yes, the JVM takes advantages of the underlying OS threads. In ORP, I mapped 1:1:1. One java.lang.Thread to one ORP internal thread manager that in turn mappped to one underlying OS thread. This works fine for apps that run only a few threads. It may be a bottleneck for highly threaded apps running on a multicore. Most likely the merged/unified thread scheduler will be written in a type-safe language such as Java. The interesting long term question is when will the entire JVM be merge into the underlying OS? And when will the resultant JVM/OS be re-written in a type-safe language? I suspect a modular Harmony that allows a mix and match of components in ansi C (popular with the OS crowd) and components written in Java/C# will be very useful. I've been thinking the same. I was nudged in the direction of compromise, that realistically, we'll be wanting to use pieces written in Java. Yes. Exactly. I don't want to see Harmony reinvent the OS for stuff like integrated threading and GC/virt mem mgmt. when we could take advantage of exising code. And I'm still going through ANSI C anti-withdrawal. I was looking at some C code (JamVM?) and the whole thing gave me the shakes. :) geir On 5/22/05, Rodrigo Kumpera [EMAIL PROTECTED] wrote: Green threads have a lot of problems that are hard to solve. You have to deal with blocking function, interupts, syscall restarts, blocking native code, etc... JikesRVM handles that gracefully? My impression is that everyone is dropping this M:N model because of implementation issues. BEA dropped it on jrockit. IBM was developing such system for posix threads in linux, but a simple 1:1 that solved some scalability problems in the kernel was choosen. On 5/22/05, Steve Blackburn [EMAIL PROTECTED] wrote: The Jikes RVM experience is kind of interesting... From the outset, one of the key goals of the project was to achieve much greater levels of scalability than the commercial VMs could deliver (BTW, the project was then known as Jalapeno). The design decision was to use a multiplexed threading model, where the VM scheduled its own green threads on top of posix threads, and multiple posix threads were supported. One view of this was that it was pointless to have more than one posix thread per physical CPU (since multiple posix threads would only have to time slice anyway). Under that world view, the JVM might be run on a 64-way SMP with 64 kernel threads onto which the user threads were mapped. This resulted in a highly scalable system: one of the first big achievements of the project (many years ago now) was enormously better scalability than the commercial VMs on very large SMP boxes. I was discussing this recently and the view was put that really this level of scalability was probably not worth the various sacrifices associated with the approach (our load balancing leaves something to be desired, for example). So as far as I know, most VMs these days just rely on posix style threads. Of course in that case your scalability will largely depend on your underlying kernel threads implementation. As a side note, I am working on a project with MITRE right now where we're implementing coroutine support in Jikes RVM so we can support massive numbers of coroutines (they're using this to run large scale scale simulations). We've got the system pretty much working and can support 10 of these very light weight threads. This has been demoed at MITRE and far outscales the commercial VMs. We achieve it with a simple variation of cactus stacks. We expect that once completed, the MITRE work will be contributed back to Jikes RVM. Incidentally, this is a good example of
Re: FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/)
Is there a link from the main page? -- dims On 5/23/05, Nick Lothian [EMAIL PROTECTED] wrote: [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. -- Davanum Srinivas - http://webservices.apache.org/~dims/
RE: FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/)
Nick, Thanks for getting a FAQ started. As we develop a group synergy, people like me can simply go to the relevant place there and RTFM instead of having to ask questions like my Java-in-Java performance question. One thing I would like to see people contribute to this FAQ is performance information per my original question back to Steve Blackburn and the (whole) list, whose answer you posted on this new FAQ. Hard performance numbers on various aspects of different designs will _really_ help us as a community get some idea of what works and what doesn't for various issues in a Harmony compiler and JVM. Dan Lydick [Original Message] From: Nick Lothian [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 5/22/05 7:20:54 PM Subject: FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/) =20 [snip] Does anyone have any benchmarks on such designs? As a hard-core real-time and device driver guy, I am rather=20 skeptical=20 that this is anything else but a conflict in requirements, runtime=20 performance in execution speed versus interpretability and/or=20 compilability of the runtime module. But then again, I've only been working with Java at all for=20 less than=20 four years :-) =20 The discussion has been rehashed a lot of times. I'd like to=20 see it put to rest (perhaps we need a technical FAQ?). See=20 the end of this email for a brief answer anyway...* =20 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]
Re: FAQ (was RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/)
yes :) I checked that too.. geir On May 23, 2005, at 9:52 AM, Davanum Srinivas wrote: Is there a link from the main page? -- dims On 5/23/05, Nick Lothian [EMAIL PROTECTED] wrote: [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. -- Davanum Srinivas - http://webservices.apache.org/~dims/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[arch] The Third Way : C/C++ and Java and lets go forward
I'd like to formally propose what I think many have been thinking and maybe have already suggested - that we'll need to combine both C/C++ and Java in this effort. After thinking about it, I don't really see upside to having two parallel tracks, when in fact we can and should be working together. So, to do that : I. [VM Kernel] Start with a core 'kernel' in C/C++ that provides intrinsics needed by the other modules. II. [Modular VM Architecture] Clearly define the other modules, what intrinsics they need from the core kernel, and what relationships they have to other modules III. [VM-Class library Interface] Begin seriously examining the GNU Classpath VM interface, iteratively producing a Common Classlibrary Interface that we can ask GNU Classpath to implement. Right now, they have a VM interface that is a great starting point, but I get the impression that there is a whole suite of intrinsic VM functionality that should be standardized and exposed to the class library by the VM. To do this I'd like to 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. b) Consider starting a second mail list harmony-arch, for modularity discussions, to separate out the traffic from the dev traffic. Lets get moving. Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Jam VM as Seed : request for license grant (Was Re: JIRA and SVN)
On May 21, 2005, at 6:49 PM, Robert Lougher wrote: The major problem with JamVM as regards Harmony is that it is currently licensed under the GPL. I originally had some specific reasons for doing this, however, I am open to suggestions about different licensing models, e.g. dual-licensing, adoption of LGPL or a linking exception as in GNU Classpath. Assuming the license issue could be sorted out, and if (and it's a big if) JamVM was adopted as one of the seed VMs my next concern would be what happens next. Would it be a fork? Would I continue to work on JamVM as now? Of course, change is not necessarily a bad thing. Robert, I'd like to cut to the chase and ask the following... I was going to do in private, and happy to discuss concerns in private, but since you brought up here, I'm going to take the risk and ask : Would you consider granting a copyright license for the JamVM codebase to the Apache Software Foundation under the Apache License? This means that you simply have given us license to the code under the Apache License (which means we can do with it as we choose), and you retain the copyright to do with as you choose. We of course will not call it JamVM, and anything we do could be included in JamVM if you so chose. Ideally, we want you to participate here. However, as we'd like to use this as a seed for a VM kernel, modularizing and implementing parts in probably very strange ways, and we'd want it to be able to change as needed w/o affecting the existing users of JamVM. I'm averse to calling it a fork as that denotes some sort of taking away or duplication or such - rather, I'd like to think of this as a contribution to seed what I think will be a very different result. Any interest? :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] The Third Way : C/C++ and Java and lets go forward
I still think a java-in-java solution is the way to go. All components can be tested from a JVM until it can hosts itself. The only reason for using C/C++ is with a vm as seed. If the objective is to write a high performance JVM, having a vm with an interpreter doesn't help much. Starting with java, it's more propable that we can have a nice non-optimizing JIT and runtime by the same time the C/C++ effort have a working baseline compiler. jikesRVM cannot be licensed under the ASL, but what about MMtk? Rodrigo On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'd like to formally propose what I think many have been thinking and maybe have already suggested - that we'll need to combine both C/C++ and Java in this effort. After thinking about it, I don't really see upside to having two parallel tracks, when in fact we can and should be working together. So, to do that : I. [VM Kernel] Start with a core 'kernel' in C/C++ that provides intrinsics needed by the other modules. II. [Modular VM Architecture] Clearly define the other modules, what intrinsics they need from the core kernel, and what relationships they have to other modules III. [VM-Class library Interface] Begin seriously examining the GNU Classpath VM interface, iteratively producing a Common Classlibrary Interface that we can ask GNU Classpath to implement. Right now, they have a VM interface that is a great starting point, but I get the impression that there is a whole suite of intrinsic VM functionality that should be standardized and exposed to the class library by the VM. To do this I'd like to 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. b) Consider starting a second mail list harmony-arch, for modularity discussions, to separate out the traffic from the dev traffic. Lets get moving. Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
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 __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Geir Magnusson Jr. wrote: (for the record, this isn't about not doing Java or not doing JikesRVM, but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going...) Excuse me if I'm missing something, but wouldn't it be necessary to implement parts of the VM or the class library in native code anyway? I'm thinking about code to access e.g. resources like I/O devices, sound etc.? Or is this discussion C vs Java restricted to the bytecode executing part of the VM? Tor
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?
Re: JIRA and SVN
On May 23, 2005, at 5:33 PM, Bryce Leo wrote: 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? It's gotta be the same experience for a user as if using Sun's implementation. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Sun lashes out at open source J2SE
http://www.infomaticsonline.co.uk/2135503 Sun lashes out at open source J2SE Apache plans dubbed 'destructive' Sun Microsystems has expressed serious doubts about the usefulness of the latest Apache Foundation project to create an open source implementation of the Java 2 Standard Edition (J2SE). In an interview with *vnunet.com* http://www.vnunet.com, James Gosling, Java creator and Sun vice president in charge of the programming language, explained that he did not understand why the open source consortium was undertaking the project. I would never do that, he said about Apache's Project Harmony. There are so many more interesting things to do with my life. The Apache Foundation announced the project *earlier this month* http://www.infomaticsonline.co.uk/2127323. The organisation aims to collect a group of developers and create an open source implementation of the J2SE, which is needed to run Java code on a desktop computer. Sun requires J2SE implementations to pass rigorous testing requirements before they can call themselves Java compliant. While this ensures compatibility between the different J2SEs, it also means that the functionalities of the final product are identical to Sun's existing offering. Sun put the detailed requirements in place to prevent forking, a fragmentation of the language that would force software developers to certify their code for each fork. A similar development with Linux allowed Red Hat and SuSE to become the de facto standards. Major software vendors, such as Oracle and Computer Associates, now certify their software only for these Linux distributions. Sun welcomes contributions from outside the company to the source code, and has a Java Community Process in place to foster discussion within the developer community and encourage input on the future direction of the language. The inability to fork Java is the only major difference between the software licence that Sun uses for Java and the GPL-like licence that the Apache Foundation will use, according to Gosling. [Apache] says a lot of words about why they want to do it. Exactly why is it critical to have a delta between our source licence and the source licence that they think is appropriate? he said. I understand why they would like it to be different. From our point of view that would actually be more destructive than helpful. It boils down to forking: they believe that the ability to fork is an absolutely critical right. Gosling claimed that Java developers of enterprise software support Sun in its refusal to open the source code of Java. But they are eclipsed by more vocal open source advocates. If we could get the enterprise software architects to be as vocal as the Slashdot crowd, it would be a really interesting discussion, he said. Sun will not contribute to the project, Gosling said, revoking a comment that another Sun vice president made on his blog earlier. We hardly have the energy to work on our [J2SE implementation]. We'll be glad to get co-operative and helpful, but there is only so much energy that is free and donatable, Gosling told *vnunet.com* http://www.vnunet.com. In response to Gosling's remarks, Geir Magnusson, an independent software developer with the Foundation, told /vnunet.com/ that Apache does not aim to fork Java. An open source J2SE implementation could allow the software to spread to new devices, according to Magnusson, who pointed out that Sun's J2SE only supports Solaris, Linux and Windows. This is about producing a J2SE implementation that can be taken and ported and used in more places, he said. If I am building a device that uses Java and I could get a complete J2SE implementation from Apache, then we would have a new place for Java. It would be nice if every Linux distribution came with Java. Java should be like a dial-tone. Magnusson added that current J2SE providers, such as IBM, BEA and Sun, all have to build and test their own software. An open source implementation would allow them to share that work. He is not surprised by Sun's lack of enthusiasm about his latest project, however. Magnusson has spoken with the company about Harmony and has invited it to participate. Sun is a little sceptical that we are able to do it, he said. Sun has provided Magnusson with a slot at the upcoming Java One conference from 27-30 June in San Francisco. The development of the open source J2SE software is expected to take several years.
Re: JIRA and SVN
I agree. I'm afraid the TCK has many hundreds of Swing tests. (javax_swing in JCK test tree). Not all require robotic interaction; they may be tests of the data structures or exceptions and suchlike in the Swing libraries. Therefore it is yet another area where Harmony will need quality libraries to meet the j2se spec. Whilst it might be tempting to find a workaround, i can't see it being a worthwile solution. It'll just create more issues down the line I think. -gerry On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 23, 2005, at 5:33 PM, Bryce Leo wrote: 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? It's gotta be the same experience for a user as if using Sun's implementation. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Gerry Steele x74521/+353-1-8199 521 http://blogs.sun.com/roller/page/gerrys [EMAIL PROTECTED] OR [EMAIL PROTECTED]
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.
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is not the case Geir. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). That's it. The kernel of the VM can be entirely written in Java. Whether or not we chose to do that is another matter, but your comment above is technically incorrect, and therefore should not be the basis on which we start coding. This misconception highlights why it is that I think we need a seeding process to gain some collective understanding before we start cutting code for a new VM core. This requires some patience but I think will make the difference between us producing a) something that is free, runs OK, and is portable, from b) something that leverages the outstanding collective pool of ideas at the table (ovm, gcj, kaffe, joeq, jamvm, jc, orp, mudgevm, jikesrvm, etc etc) to deliver what I think could be the best performing, most exciting VM, free or non-free. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I understand that it is important that we seize the enthusiasm of the list and start working, but respectfully, I think that cutting code for a VM kernel right now would be a bad mistake, one that might be gratifying in the short term but that is likely to lay the wrong foundation for what I think may become the most exciting VM project yet. --Steve
Inventory of assets
The wealth of ideas that are coming to the table is impressive. I suggest that we establish some sort of inventory of our assets (presumably on the wiki). I think that such a resource will be enormously helpful to a project like this one which is trying to bring together a huge pool of enthusiasm, prior work and outstanding research. If this project could produce a VM that literally combined the best of all of the work at the table, it would be a formidable VM indeed. By assets, I mean everything from the concrete (donated code), to the more abstract (resources such as papers like the one Andy posted to the list yesterday). I think that if we maintain this as we go along, it could prove to be a really valuable resource. To me this is our strength---so many different individuals bringing different expertise to the project, from code to ideas. If we can catalog that wealth and therefore have it at our collective fingertips, I think the chances of this project capitalizing on those ideas and doing really exciting things will increase greatly. I can imagine a tree like structure, with leaves on the tree being assets, each one described briefly---if code, then the level of availability and license, and perhaps a summary with pointers to more info. If a paper, then a short summary and a pointer, etc etc etc. For example, I think all of the VMs we're aware of should be leaves of a VM node in the tree. The Boehm collector adn MMTk are obvious leaves of the VM.GC node. The paper Andy raised could be added to VM.interpreter. It may in fact be a graph, with, JamVM, for example getting a mention under VM.interpreter as well as VM and OVM could be under VM and VM.java-in-java, etc etc etc. In a relatively short period of time, this could become a great repository of the state of the art in VM design and implementation. It may then be that the technical FAQ simply becomes a set of references to the inventory of ideas. --Steve
Re: Inventory of assets
On May 23, 2005, at 9:15 PM, Steve Blackburn wrote: The wealth of ideas that are coming to the table is impressive. I suggest that we establish some sort of inventory of our assets (presumably on the wiki). I think that such a resource will be enormously helpful to a project like this one which is trying to bring together a huge pool of enthusiasm, prior work and outstanding research. If this project could produce a VM that literally combined the best of all of the work at the table, it would be a formidable VM indeed. By assets, I mean everything from the concrete (donated code), to the more abstract (resources such as papers like the one Andy posted to the list yesterday). I think that if we maintain this as we go along, it could prove to be a really valuable resource. To me this is our strength---so many different individuals bringing different expertise to the project, from code to ideas. If we can catalog that wealth and therefore have it at our collective fingertips, I think the chances of this project capitalizing on those ideas and doing really exciting things will increase greatly. I can imagine a tree like structure, with leaves on the tree being assets, each one described briefly---if code, then the level of availability and license, and perhaps a summary with pointers to more info. If a paper, then a short summary and a pointer, etc etc etc. For example, I think all of the VMs we're aware of should be leaves of a VM node in the tree. The Boehm collector adn MMTk are obvious leaves of the VM.GC node. The paper Andy raised could be added to VM.interpreter. It may in fact be a graph, with, JamVM, for example getting a mention under VM.interpreter as well as VM and OVM could be under VM and VM.java-in-java, etc etc etc. In a relatively short period of time, this could become a great repository of the state of the art in VM design and implementation. It may then be that the technical FAQ simply becomes a set of references to the inventory of ideas. I thought we were already doing this. Feel free to reorganize in a way that you see adds value. Whatever way you set will probably be the way we go forward. :) geir --Steve -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
＞It would be great if people would bundle Harmony with stuff (and plan ＞to do it w/ Geronimo when that time comes), bit it's way out of scope ＞for *this* project to get into the business of reditributing software ＞from outside of the ASF. Hum... I still think there is a minimum distribution effort to be done (call that marketing if you want) to get people to actually test the VM, as in the beginning it might be very, very, very unlikely that absolutely everything runs out of the box as replacement for J2SE 5 or 6... So we will need to help them try it out. (Basically, to me some nice IDE + app-server + a few dummy examples, swing jsf for instance, is the bare minimum to provide as a demo-micro-distribution-to-test-it-in-reasonable-situations; the IDE only might be non-ASF, as I don’t think there is a widely accepted ASF-IDE [well, yes: Eclipse plugins for Tapestry co. :-); please accept my apologies if there is one, my point is not selling Eclipse in particular but having an IDE to play with the VM, for instance to test practically its debugging interface, and show it to others]) Just think of it in OS terms as a micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is not to be covered by NIH syndrome in my opinion, but rather a way to prove it actually works to decision makers. (After all, mono bundles mono with monodevelop [or rather monodevelop with mono, I think], and Sun bundles Netbeans with J2SE...) Just the same as if you develop, say, a 'new simulation algorithm for reaction-diffusion discrete systems, which is "discrete, adaptive" '[1]. In order to get credit from ordinary people (who might not be familiar with its technical beauty, right?), even if the scope of this project is on soft architecture and math analysis, you might have to provide scientifically uninteresting display that it works... (Spiraling pattern for simplified models of myocardium cells electrophysiology: that is, simulation of cardiac arrhythmia in dummy demo-only situation, so here the mystery of what it is ends here [2]) That is, with some 'out of scope' effort you get images for the layman to be impressed... To come back to more soft-only concerns, IMHO providing distributors with the minimum tool they need to polish the VM-to-VM discrepancies and external developers the minimum tools they need to test their soft on the Harmony VM (and get a chance to actually do something - not just: 'it does not work' - if it does not work the way they planned it) might be a big ROI, comparatively small effort. A VM without the bare minimum support tools might appear a bit useless to many people (and also impractical to test with an ergonomic, long-lasting experience of beautiful-looking piece of software). If you take, say, the FreeBSD case, you don’t have much choice for instance for the VM you use with your favorite IDE, so that ipso facto you stick with the VM you get in stock (because the other VMs might be good, but if it’s a nightmare to reconfigure it all to use your VM of choice with your favorite IDE...), just like IE sticks with many win$ users. As a use case, if I want to test a piece of software, well I would like it to be kind of "download it and play". Regards, RB [1] Sorry I take examples of my own... (Well, the research I once did) [2] It was so simplified it was meaningless in my opinion, but I got my credits with it... -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 8:58 PM To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ On May 22, 2005, at 9:27 PM, Renaud BECHADE wrote: ＞ No. Why would we do this? People tend to be lazy. If they have a bundle with one VM, then they will use that VM, for most of them, IMHO. I seriously doubt we can have people trust an alternative VM if it is not a piece of cake (sort of "with a one liner on the console you are started") to develop with it, and as it is unlikely it will support everything perfectly at the beginning (to convince you let us consider running .NET soft on a Linux/Mono machine, or XSP code on a FreeBSD/mono machine - sometimes it crashes badly, or again freeware support of Flash swf, all of which can have slightly strange behaviors sometimes, if compared with commercial equivalents, so that a development that is not started /from the beginning/ with them might get into troubles) there will be some intensive testing to do on real applications, which might involve some patches on
RE: JIRA and SVN
I think there are Swing wrappers for SWT, which can wrap win$ / GTK / MacOS-X-Carbon. (No guaranty so far as code completeness is concerned, so please trust it and die...) RB -Original Message- From: Bryce Leo [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 6:34 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?
Re: [arch] The Third Way : C/C++ and Java and lets go forward
On May 23, 2005, at 8:23 PM, Steve Blackburn wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. I sort of agree. It's clear we need more clarity about modularization (hint, hint) and that we need to be going on that (hint, hint), but I would be dollars to donuts that you could frame out a simple high level modular structure that we could start refactoring a donated core from the beginning to start playing. I want to see people get their hands on showing how a VM core can be comprised of Java and C++. Also, I would bet that you could give us a laundry list of core kernel intrinsic APIs that we'd need to develop/refactor/import/etc for the Java pieces of the VM. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is not the case Geir. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). That's it. The kernel of the VM can be entirely written in Java. Whether or not we chose to do that is another matter, but your comment above is technically incorrect, and therefore should not be the basis on which we start coding. Maybe we're just having a semantic problem - I would consider the bootstrap part and the OS interaction part the kernel, and probably some non-OS pieces like helping out w/ memory management - letting the java work with raw pointers. There may be other pieces that you consider kernel that are in Java, and I'm fine with that. Please, just tell us what they are. This misconception highlights why it is that I think we need a seeding process to gain some collective understanding before we start cutting code for a new VM core. This requires some patience but I think will make the difference between us producing a) something that is free, runs OK, and is portable, from b) something that leverages the outstanding collective pool of ideas at the table (ovm, gcj, kaffe, joeq, jamvm, jc, orp, mudgevm, jikesrvm, etc etc) to deliver what I think could be the best performing, most exciting VM, free or non-free. define free. It has many meanings around here ;) Yes, this is just the seeding process given a kick. You want to show up with JikesRVM for the core functionality, I will do everything I can to help you get the paperwork done. But will need the direct interaction code, and the bootstraping code, and starting w/ a small existing project to help us on our way is all I was doing. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. That wasn't the intention, in that it's not the core as a VM, but core as the kernel that we need for the modules, which may or may not be in Java. I understand that there will be parts that will be best done in Java - I'm all for it. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I understand that it is important that we seize the enthusiasm of the list and start working, but respectfully, I think that cutting code for a VM kernel right now would be a bad mistake, one that might be gratifying in the short term but that is likely to lay the wrong foundation for what I think may become the most exciting VM project yet. We're not pouring cement and bending re-bar here. I'd be happy to abandon anything we start with once we figure out what is better, or if some other donation that more fits our intended design comes along. I'm 100% against looking around at parts, and cobbling something together. I'm 100% for having parts to play with our ideas, but setting out an architecture and roadmap that we design, we decide on, and then we instantiate via fresh code, donation or other. So that said, are you still so against it? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote: It would be great if people would bundle Harmony with stuff (and plan to do it w/ Geronimo when that time comes), bit it's way out of scope for *this* project to get into the business of reditributing software from outside of the ASF. Hum... I still think there is a minimum distribution effort to be done (call that marketing if you want) to get people to actually test the VM, as in the beginning it might be very, very, very unlikely that absolutely everything runs out of the box as replacement for J2SE 5 or 6... So we will need to help them try it out. Yes! And this is classic behavior for OSS projects - once you have something useful, you go out and proselytize, helping other projects see the value, and use it. So you go out and get Eclipse to bundle with it, you get Geronimo to bundle with it, you get JBoss to bundle with it, you get JOnAS to bundle with it, you get Tomcat to bundle with it, you get And then you learn from their bundling efforts and make the thing even easier to use in that way. But distributing Eclipse or JBoss from here? No Just think of it in OS terms as a micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is not to be covered by NIH syndrome in my opinion, but rather a way to prove it actually works to decision makers. (After all, mono bundles mono with monodevelop [or rather monodevelop with mono, I think], and Sun bundles Netbeans with J2SE...) I'd prefer we don't re-distribute other people's software unless part of the distribution for which the Apache project provides top-line value. [SNIP] To come back to more soft-only concerns, IMHO providing distributors with the minimum tool they need to polish the VM-to-VM discrepancies and external developers the minimum tools they need to test their soft on the Harmony VM (and get a chance to actually do something - not just: 'it does not work' - if it does not work the way they planned it) might be a big ROI, comparatively small effort. That's an entirely different kettle of fish, and I support that. A VM without the bare minimum support tools might appear a bit useless to many people (and also impractical to test with an ergonomic, long- lasting experience of beautiful-looking piece of software). If you take, say, the FreeBSD case, you dont have much choice for instance for the VM you use with your favorite IDE, so that ipso facto you stick with the VM you get in stock (because the other VMs might be good, but if its a nightmare to reconfigure it all to use your VM of choice with your favorite IDE...), just like IE sticks with many win$ users. I don't understand this argument. If our J2SE implementation is feature-comparable to the one from Sun, IBM or BEA, why would we need to add Eclipse onto it? As a use case, if I want to test a piece of software, well I would like it to be kind of download it and play. Yes! So we go out there and get everyone to bundle with our J2SE distribution. We go there, do the work, and help them. :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Geir, Am convinced that we can write a JVM in pure java with minimal C/C++. How about we poll the VM candidates on who wants to help seed the project, ask them to do the paperwork, then we can get folks on board as committers and let them play in sandboxes (see below). Folks who do the work will then get to decide the future direction. We don't have to make the technical decision now before the committers are on board. What do you think? Steve, As a mentor, i agree with you whole heartedly. How do we go about this process of designing the core for harmony? Could we say strip down say JamVM/JCVM to create a bootstrapper (OS dependent stuff ONLY) for a stripped down JikesRVM in our sandbox to illustrate the validity of writing the almost the whole JVM in java? [Nothing like working code to get juices flowing]. My problem is that i haven't done this (writing a JVM) before, so am itching to do something that will help me understand better the problems/challenges involved and help me on deciding what to look for in the other existing VM's that we can leverage/use. Thanks, dims On 5/23/05, Steve Blackburn [EMAIL PROTECTED] wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is not the case Geir. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). That's it. The kernel of the VM can be entirely written in Java. Whether or not we chose to do that is another matter, but your comment above is technically incorrect, and therefore should not be the basis on which we start coding. This misconception highlights why it is that I think we need a seeding process to gain some collective understanding before we start cutting code for a new VM core. This requires some patience but I think will make the difference between us producing a) something that is free, runs OK, and is portable, from b) something that leverages the outstanding collective pool of ideas at the table (ovm, gcj, kaffe, joeq, jamvm, jc, orp, mudgevm, jikesrvm, etc etc) to deliver what I think could be the best performing, most exciting VM, free or non-free. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I understand that it is important that we seize the enthusiasm of the list and start working, but respectfully, I think that cutting code for a VM kernel right now would be a bad mistake, one that might be gratifying in the short term but that is likely to lay the wrong foundation for what I think may become the most exciting VM project yet. --Steve -- Davanum Srinivas - http://webservices.apache.org/~dims/
RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
＞I don't understand this argument. If our J2SE implementation is ＞feature-comparable to the one from Sun, IBM or BEA, why would we need ＞to add Eclipse onto it? As a demonstrator： "just test it" [TM]. Also, as I said before, if its entry level for developers is high ( configuration with Eclipse or some other candidate, the lazy effect, you see), then we are digging our grave, because the best way to have other projects bundle with the VM is to help them play with it in the first time. Regards, RB -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 10:49 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote: ＞It would be great if people would bundle Harmony with stuff (and plan ＞to do it w/ Geronimo when that time comes), bit it's way out of scope ＞for *this* project to get into the business of reditributing software ＞from outside of the ASF. Hum... I still think there is a minimum distribution effort to be done (call that marketing if you want) to get people to actually test the VM, as in the beginning it might be very, very, very unlikely that absolutely everything runs out of the box as replacement for J2SE 5 or 6... So we will need to help them try it out. Yes! And this is classic behavior for OSS projects - once you have something useful, you go out and proselytize, helping other projects see the value, and use it. So you go out and get Eclipse to bundle with it, you get Geronimo to bundle with it, you get JBoss to bundle with it, you get JOnAS to bundle with it, you get Tomcat to bundle with it, you get And then you learn from their bundling efforts and make the thing even easier to use in that way. But distributing Eclipse or JBoss from here? No Just think of it in OS terms as a micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is not to be covered by NIH syndrome in my opinion, but rather a way to prove it actually works to decision makers. (After all, mono bundles mono with monodevelop [or rather monodevelop with mono, I think], and Sun bundles Netbeans with J2SE...) I'd prefer we don't re-distribute other people's software unless part of the distribution for which the Apache project provides top-line value. [SNIP] To come back to more soft-only concerns, IMHO providing distributors with the minimum tool they need to polish the VM-to-VM discrepancies and external developers the minimum tools they need to test their soft on the Harmony VM (and get a chance to actually do something - not just: 'it does not work' - if it does not work the way they planned it) might be a big ROI, comparatively small effort. That's an entirely different kettle of fish, and I support that. A VM without the bare minimum support tools might appear a bit useless to many people (and also impractical to test with an ergonomic, long- lasting experience of beautiful-looking piece of software). If you take, say, the FreeBSD case, you don’t have much choice for instance for the VM you use with your favorite IDE, so that ipso facto you stick with the VM you get in stock (because the other VMs might be good, but if it’s a nightmare to reconfigure it all to use your VM of choice with your favorite IDE...), just like IE sticks with many win$ users. I don't understand this argument. If our J2SE implementation is feature-comparable to the one from Sun, IBM or BEA, why would we need to add Eclipse onto it? As a use case, if I want to test a piece of software, well I would like it to be kind of "download it and play". Yes! So we go out there and get everyone to bundle with our J2SE distribution. We go there, do the work, and help them. :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
By this I mean sort of "stripped down to its maximum demo Eclipse" (usable for small projects, but without all those fancy plugins). This is not really redistributing but rather "pamphleting"... RB -Original Message- From: Renaud BECHADE [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 11:10 AM To: harmony-dev@incubator.apache.org Subject: RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ ＞I don't understand this argument. If our J2SE implementation is ＞feature-comparable to the one from Sun, IBM or BEA, why would we need ＞to add Eclipse onto it? As a demonstrator： "just test it" [TM]. Also, as I said before, if its entry level for developers is high ( configuration with Eclipse or some other candidate, the lazy effect, you see), then we are digging our grave, because the best way to have other projects bundle with the VM is to help them play with it in the first time. Regards, RB -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 10:49 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote: ＞It would be great if people would bundle Harmony with stuff (and plan ＞to do it w/ Geronimo when that time comes), bit it's way out of scope ＞for *this* project to get into the business of reditributing software ＞from outside of the ASF. Hum... I still think there is a minimum distribution effort to be done (call that marketing if you want) to get people to actually test the VM, as in the beginning it might be very, very, very unlikely that absolutely everything runs out of the box as replacement for J2SE 5 or 6... So we will need to help them try it out. Yes! And this is classic behavior for OSS projects - once you have something useful, you go out and proselytize, helping other projects see the value, and use it. So you go out and get Eclipse to bundle with it, you get Geronimo to bundle with it, you get JBoss to bundle with it, you get JOnAS to bundle with it, you get Tomcat to bundle with it, you get And then you learn from their bundling efforts and make the thing even easier to use in that way. But distributing Eclipse or JBoss from here? No Just think of it in OS terms as a micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is not to be covered by NIH syndrome in my opinion, but rather a way to prove it actually works to decision makers. (After all, mono bundles mono with monodevelop [or rather monodevelop with mono, I think], and Sun bundles Netbeans with J2SE...) I'd prefer we don't re-distribute other people's software unless part of the distribution for which the Apache project provides top-line value. [SNIP] To come back to more soft-only concerns, IMHO providing distributors with the minimum tool they need to polish the VM-to-VM discrepancies and external developers the minimum tools they need to test their soft on the Harmony VM (and get a chance to actually do something - not just: 'it does not work' - if it does not work the way they planned it) might be a big ROI, comparatively small effort. That's an entirely different kettle of fish, and I support that. A VM without the bare minimum support tools might appear a bit useless to many people (and also impractical to test with an ergonomic, long- lasting experience of beautiful-looking piece of software). If you take, say, the FreeBSD case, you don’t have much choice for instance for the VM you use with your favorite IDE, so that ipso facto you stick with the VM you get in stock (because the other VMs might be good, but if it’s a nightmare to reconfigure it all to use your VM of choice with your favorite IDE...), just like IE sticks with many win$ users. I don't understand this argument. If our J2SE implementation is feature-comparable to the one from Sun, IBM or BEA, why would we need to add Eclipse onto it? As a use case, if I want to test a piece of software, well I would like it to be kind of "download it and play". Yes! So we go out there and get everyone to bundle with our J2SE distribution. We go there, do the work, and help them. :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Hi, Steve Blackburn wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. You could be right in that it is a technical mistake but in the long wrong it may prove not to be useful for helping to kick start the community and thus not a community mistake. Discussion about abstract concepts and implementation strategies with no concrete code that people can look at and play with can lead to never ending discussions that never seem to progress. Give people some code and some leeway to experiment for themselves and they are much more likely to come around to understanding the problem and thus being able to agree on a way forward. Paraphrasing what was said earlier in this mailing list crap code and good ideas will lead to a good community while other combinations may not. Experimenting with a codebase will at least give people a feel for other members of the community and how they cut code. This will be worth it even if the entire codebase gets thrown out or rewritten from scratch. Some of the people here are unlikely to be swayed from C/C++ for VM crowd with just words - code which they can profile and generate performance statistics with is much more likely to convince them. Don't get me wrong - discussion is good and you have convinced me (who was firmly in the C for VM camp) that Java In Java is a good approach - I would love to hear more about it (especially how synchronization, volatile and monitors could be plugged in) but there has been enough talk and probably a good time for action to start ;) So I agree with you that this move may be a technical mistake but I would put forth the idea that it may be a bigger community mistake if something concrete does not start soon. FWIW I am not involved with Apache or any of the VM/Classpath projects but I suspect that this is a way forward that would be useful using the Apache way. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). I guess I was under the wrong impression aswell. I thought that JRVM required another JVM during build to compile its own codebase and create an executable image. JRVM would then use this image during its execution. Could we use a simple interpreter for this initial stage? Or am I completely off base. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I don't disagree with you but I guess I think it would be more useful to place community correctnes over technical correctnes at the begining. Once a group is working together they should be able to migrate to JRVM or whatever could be used as the bases. -- Cheers, Peter Donald The only way to get rid of a temptation is to yield to it. - Oscar Wilde (1854-1900)
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Peter Donald wrote: Hi, Steve Blackburn wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. You could be right in that it is a technical mistake but in the long wrong it may prove not to be useful for helping to kick start erg ... should be ...but in the long wrong it may prove to be useful for helping to kick start... the community and thus not a community mistake. Discussion about abstract concepts and implementation strategies with no concrete code that people can look at and play with can lead to never ending discussions that never seem to progress. Give people some code and some leeway to experiment for themselves and they are much more likely to come around to understanding the problem and thus being able to agree on a way forward. Paraphrasing what was said earlier in this mailing list crap code and good ideas will lead to a good community while other combinations may not. Experimenting with a codebase will at least give people a feel for other members of the community and how they cut code. This will be worth it even if the entire codebase gets thrown out or rewritten from scratch. Some of the people here are unlikely to be swayed from C/C++ for VM crowd with just words - code which they can profile and generate performance statistics with is much more likely to convince them. Don't get me wrong - discussion is good and you have convinced me (who was firmly in the C for VM camp) that Java In Java is a good approach - I would love to hear more about it (especially how synchronization, volatile and monitors could be plugged in) but there has been enough talk and probably a good time for action to start ;) So I agree with you that this move may be a technical mistake but I would put forth the idea that it may be a bigger community mistake if something concrete does not start soon. FWIW I am not involved with Apache or any of the VM/Classpath projects but I suspect that this is a way forward that would be useful using the Apache way. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). I guess I was under the wrong impression aswell. I thought that JRVM required another JVM during build to compile its own codebase and create an executable image. JRVM would then use this image during its execution. Could we use a simple interpreter for this initial stage? Or am I completely off base. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I don't disagree with you but I guess I think it would be more useful to place community correctnes over technical correctnes at the begining. Once a group is working together they should be able to migrate to JRVM or whatever could be used as the bases. -- Cheers, Peter Donald The only way to get rid of a temptation is to yield to it. - Oscar Wilde (1854-1900)
Re: [arch] The Third Way : C/C++ and Java and lets go forward
On May 23, 2005, at 9:54 PM, Davanum Srinivas wrote: Geir, Am convinced that we can write a JVM in pure java with minimal C/C++. Why? If it has C/C++, it's not pure Java. Period. This isn't about whether or not that it can be done in Java, or a way to get it into C/C++. Lets get over that misconception right now. I'm sure that major parts can be done in Java - it's been demonstrated by JikesRVM, and lots of experienced VM people point in that direction, even with a C/C++ core. I have no problem with that. How about we poll the VM candidates on who wants to help seed the project, ask them to do the paperwork, then we can get folks on board as committers and let them play in sandboxes (see below). Folks who do the work will then get to decide the future direction. We don't have to make the technical decision now before the committers are on board. What do you think? I don't see what we gain. We want to create *our design*, not make frankenVM. The point of starting with a small seed C/C++ kernel is to get the bootstrap and intrinsics support that *any* VM will need, pure C, pure Java, or mixed. Our discussions will point to where we have to refactor. On top of that, we build what we decide to build, not what we find out there, unless what we find out there is what we designed for. geir Steve, As a mentor, i agree with you whole heartedly. How do we go about this process of designing the core for harmony? Could we say strip down say JamVM/JCVM to create a bootstrapper (OS dependent stuff ONLY) for a stripped down JikesRVM in our sandbox to illustrate the validity of writing the almost the whole JVM in java? [Nothing like working code to get juices flowing]. My problem is that i haven't done this (writing a JVM) before, so am itching to do something that will help me understand better the problems/challenges involved and help me on deciding what to look for in the other existing VM's that we can leverage/use. Thanks, dims On 5/23/05, Steve Blackburn [EMAIL PROTECTED] wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is not the case Geir. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). That's it. The kernel of the VM can be entirely written in Java. Whether or not we chose to do that is another matter, but your comment above is technically incorrect, and therefore should not be the basis on which we start coding. This misconception highlights why it is that I think we need a seeding process to gain some collective understanding before we start cutting code for a new VM core. This requires some patience but I think will make the difference between us producing a) something that is free, runs OK, and is portable, from b) something that leverages the outstanding collective pool of ideas at the table (ovm, gcj, kaffe, joeq, jamvm, jc, orp, mudgevm, jikesrvm, etc etc) to deliver what I think could be the best performing, most exciting VM, free or non-free. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I understand that it is important that we seize the enthusiasm of the list and start working, but respectfully, I think that cutting code for a VM kernel right now would be a bad mistake, one that might be gratifying in the short term but that is likely to lay the wrong foundation for what I think may become the most exciting VM project yet. --Steve -- Davanum Srinivas - http://webservices.apache.org/~dims/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
On May 23, 2005, at 10:09 PM, Renaud BECHADE wrote: I don't understand this argument. If our J2SE implementation is feature-comparable to the one from Sun, IBM or BEA, why would we need to add Eclipse onto it? As a demonstrator just test it [TM]. Then test it! We don't have to distribute it too :) Also, as I said before, if its entry level for developers is high ( configuration with Eclipse or some other candidate, the lazy effect, you see), then we are digging our grave, because the best way to have other projects bundle with the VM is to help them play with it in the first time. Regards, RB -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 10:49 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM Candidate : JikesRVM http:// jikesrvm.sourceforge.net/ On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote: It would be great if people would bundle Harmony with stuff (and plan to do it w/ Geronimo when that time comes), bit it's way out of scope for *this* project to get into the business of reditributing software from outside of the ASF. Hum... I still think there is a minimum distribution effort to be done (call that marketing if you want) to get people to actually test the VM, as in the beginning it might be very, very, very unlikely that absolutely everything runs out of the box as replacement for J2SE 5 or 6... So we will need to help them try it out. Yes! And this is classic behavior for OSS projects - once you have something useful, you go out and proselytize, helping other projects see the value, and use it. So you go out and get Eclipse to bundle with it, you get Geronimo to bundle with it, you get JBoss to bundle with it, you get JOnAS to bundle with it, you get Tomcat to bundle with it, you get And then you learn from their bundling efforts and make the thing even easier to use in that way. But distributing Eclipse or JBoss from here? No Just think of it in OS terms as a micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is not to be covered by NIH syndrome in my opinion, but rather a way to prove it actually works to decision makers. (After all, mono bundles mono with monodevelop [or rather monodevelop with mono, I think], and Sun bundles Netbeans with J2SE...) I'd prefer we don't re-distribute other people's software unless part of the distribution for which the Apache project provides top-line value. [SNIP] To come back to more soft-only concerns, IMHO providing distributors with the minimum tool they need to polish the VM-to-VM discrepancies and external developers the minimum tools they need to test their soft on the Harmony VM (and get a chance to actually do something - not just: 'it does not work' - if it does not work the way they planned it) might be a big ROI, comparatively small effort. That's an entirely different kettle of fish, and I support that. A VM without the bare minimum support tools might appear a bit useless to many people (and also impractical to test with an ergonomic, long- lasting experience of beautiful-looking piece of software). If you take, say, the FreeBSD case, you dont have much choice for instance for the VM you use with your favorite IDE, so that ipso facto you stick with the VM you get in stock (because the other VMs might be good, but if its a nightmare to reconfigure it all to use your VM of choice with your favorite IDE...), just like IE sticks with many win$ users. I don't understand this argument. If our J2SE implementation is feature-comparable to the one from Sun, IBM or BEA, why would we need to add Eclipse onto it? As a use case, if I want to test a piece of software, well I would like it to be kind of download it and play. Yes! So we go out there and get everyone to bundle with our J2SE distribution. We go there, do the work, and help them. :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] The Third Way : C/C++ and Java and lets go forward
On May 23, 2005, at 10:31 PM, Peter Donald wrote: Peter Donald wrote: Hi, Steve Blackburn wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. You could be right in that it is a technical mistake but in the long wrong it may prove not to be useful for helping to kick start erg ... should be ...but in the long wrong it may prove to be useful for helping to kick start... I still have no clue what long wrong means. Try again? :) geir the community and thus not a community mistake. Discussion about abstract concepts and implementation strategies with no concrete code that people can look at and play with can lead to never ending discussions that never seem to progress. Give people some code and some leeway to experiment for themselves and they are much more likely to come around to understanding the problem and thus being able to agree on a way forward. Paraphrasing what was said earlier in this mailing list crap code and good ideas will lead to a good community while other combinations may not. Experimenting with a codebase will at least give people a feel for other members of the community and how they cut code. This will be worth it even if the entire codebase gets thrown out or rewritten from scratch. Some of the people here are unlikely to be swayed from C/C++ for VM crowd with just words - code which they can profile and generate performance statistics with is much more likely to convince them. Don't get me wrong - discussion is good and you have convinced me (who was firmly in the C for VM camp) that Java In Java is a good approach - I would love to hear more about it (especially how synchronization, volatile and monitors could be plugged in) but there has been enough talk and probably a good time for action to start ;) So I agree with you that this move may be a technical mistake but I would put forth the idea that it may be a bigger community mistake if something concrete does not start soon. FWIW I am not involved with Apache or any of the VM/Classpath projects but I suspect that this is a way forward that would be useful using the Apache way. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). I guess I was under the wrong impression aswell. I thought that JRVM required another JVM during build to compile its own codebase and create an executable image. JRVM would then use this image during its execution. Could we use a simple interpreter for this initial stage? Or am I completely off base. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I don't disagree with you but I guess I think it would be more useful to place community correctnes over technical correctnes at the begining. Once a group is working together they should be able to migrate to JRVM or whatever could be used as the bases. -- Cheers, Peter Donald The only way to get rid of a temptation is to yield to it. - Oscar Wilde (1854-1900) -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Geir Magnusson Jr. wrote: ...but in the long wrong it may prove to be useful for helping to kick start... I still have no clue what long wrong means. Try again? :) ...but in the long run it may prove to be useful for helping to kick start... *sigh* - Sometimes I wish my brain did not require caffeine to function.
RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
＞ ＞I don't understand this argument. If our J2SE implementation is ＞ ＞feature-comparable to the one from Sun, IBM or BEA, why would we ＞ need ＞ ＞to add Eclipse onto it? ＞ ＞ As a demonstrator： "just test it" [TM]. ＞Then test it! We don't have to distribute it too :) Well, the point is to /convince/ less passionate people. I have seen enough freeware/opensource sites that shave a zero cost tomorrow, but which soft as of today is not up to what is said should work (mind you, I am bearded, and I never shaved in 10 years). Having just one or two bundles to begin to "just play with it" (with some screenshots) IMHO is really the simplest way to convince people of practical usability. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 11:33 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ On May 23, 2005, at 10:09 PM, Renaud BECHADE wrote: ＞I don't understand this argument. If our J2SE implementation is ＞feature-comparable to the one from Sun, IBM or BEA, why would we need ＞to add Eclipse onto it? As a demonstrator： "just test it" [TM]. Then test it! We don't have to distribute it too :) Also, as I said before, if its entry level for developers is high ( configuration with Eclipse or some other candidate, the lazy effect, you see), then we are digging our grave, because the best way to have other projects bundle with the VM is to help them play with it in the first time. Regards, RB -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 10:49 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM Candidate : JikesRVM http:// jikesrvm.sourceforge.net/ On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote: ＞It would be great if people would bundle Harmony with stuff (and plan ＞to do it w/ Geronimo when that time comes), bit it's way out of scope ＞for *this* project to get into the business of reditributing software ＞from outside of the ASF. Hum... I still think there is a minimum distribution effort to be done (call that marketing if you want) to get people to actually test the VM, as in the beginning it might be very, very, very unlikely that absolutely everything runs out of the box as replacement for J2SE 5 or 6... So we will need to help them try it out. Yes! And this is classic behavior for OSS projects - once you have something useful, you go out and proselytize, helping other projects see the value, and use it. So you go out and get Eclipse to bundle with it, you get Geronimo to bundle with it, you get JBoss to bundle with it, you get JOnAS to bundle with it, you get Tomcat to bundle with it, you get And then you learn from their bundling efforts and make the thing even easier to use in that way. But distributing Eclipse or JBoss from here? No Just think of it in OS terms as a micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is not to be covered by NIH syndrome in my opinion, but rather a way to prove it actually works to decision makers. (After all, mono bundles mono with monodevelop [or rather monodevelop with mono, I think], and Sun bundles Netbeans with J2SE...) I'd prefer we don't re-distribute other people's software unless part of the distribution for which the Apache project provides top-line value. [SNIP] To come back to more soft-only concerns, IMHO providing distributors with the minimum tool they need to polish the VM-to-VM discrepancies and external developers the minimum tools they need to test their soft on the Harmony VM (and get a chance to actually do something - not just: 'it does not work' - if it does not work the way they planned it) might be a big ROI, comparatively small effort. That's an entirely different kettle of fish, and I support that. A VM without the bare minimum support tools might appear a bit useless to many people (and also impractical to test with an ergonomic, long- lasting experience of beautiful-looking piece of software). If you take, say, the FreeBSD case, you don’t have much choice for instance for the VM you use with your favorite IDE, so that ipso facto you stick with the VM you get in stock (because the other VMs
Mailing list for Wiki Changes
Hi, Is there a mailing list where wiki changes are mailed out to? -- Cheers, Peter Donald He strains to hear a whisper who refuses to hear a shout.
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Archie Cobbs wrote: Are you suggesting we do it w/ JC? :) Is there a single copyright holder such I'll have to abstain from the voting on that :-) I am not sure why not :) I think that what Geir is proposing is that Harmony start from some exisitng codebase that is hacking on and reworked as part of a learning experience for everyone as part of a stepping stone before the real VM is rewritten once the committers understand the space (community and technical). If you think JC is a good place to start for this then speak up - but you must realize that it may end up being hacked a million different ways and not look like JC at all in the end. And it may get thrown out as people start on the next VM. If you are comfortable with that then ... That approach makes sense to me. As pointed out before, JC is available license-wise [1]. My guess is that at minimum there are some useful bits that can immediately used. excellent. I'd also consider using some of the good ideas (mostly from SableVM) that JC implements, if not the actual code. For example, per-class loader memory areas, bidirectional object layout, and the threading state management. The latter in particular is a bug-prone area that has already been carefully thought out by Etienne Gagnon. Both you and Steve have suggested the same sort of approach - namely that Harmony look at different ideas implemented in different JVMs and scoop the cream of the crop off the top. However not everyone here has the experience and background to highlight the important aspects of different JVMs. So what I would suggest is that you both start a list either in Wiki or in subversion that highlights these areas and where they are implemented and the papers in which they described etc. This will make it much easier for other people to make an informed decision.
Re: Bootstrapping community (Re: [arch] The Third Way : C/C++ and Java and lets go forward)
On May 23, 2005, at 11:03 PM, Davanum Srinivas wrote: Geir, Am not sure u understood where i am coming from. (I feel that u saying that we are not going to get commit privs for folks interested till the design discussions are over AND that design decisions are going to be made on the mailing list ONLY?) Huh? I don't understand that. What I want to do is start getting people working and committing, but *also* getting some of the sophisticated design work done. I think that we can drive one from another and vice-versa. By having a little kernel-thingy (I won't call it core because after talking to Steve, it's clearly a matter of semantics) that's for our prototyping and learning, we can start working with the modularization, which as I understand it, is a current topic in VM research. Yes, I'm hoping the design decisions are made on the list, btw. :) I have trouble keeping up with the mailing list and so do others...am not saying that we have to check-in code from all the seed VM's into our repo. I want to keep the momentum going by getting committers on board, letting them share thoughts, documents and code if any (SVN repo?), may be use JIRA to document requirements etc. Right now no one knows who is going to be working and on what and how to contribute etc. Yes - that's the entire point of what I'm trying to do :) As stefano says - good ideas and bad code build communities, the other three combinations do notLet's build the community without waiting for the discussion to end on the mailing lists and let the committers/community decide on how best to move forward. We don't (mentors) have to pick the winner? do we? There's no winner. LIke I said, this isn't about blessing one thing as the solution. We aren't going to just take something from outside and say done. What I wanted is code to experiment with and adapt to what *we* design. We can add things from elsewhere as the design require (like modularize parts of JikesRVM, which I understand needs to be done...). Look at Jam. My understanding is that it sorta works, and it's very simple. It sounds like it's easy to refactor to a small, kernel- thingy that will be a basis of support for moving forward w/ the modularity. And then we can throw it out :) or not. Whatever we discover. I think we're going to learn a lot here. geir (And while I'm a mentor, I'm also a participant :) Thanks, dims On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 23, 2005, at 9:54 PM, Davanum Srinivas wrote: Geir, Am convinced that we can write a JVM in pure java with minimal C/C ++. Why? If it has C/C++, it's not pure Java. Period. This isn't about whether or not that it can be done in Java, or a way to get it into C/C++. Lets get over that misconception right now. I'm sure that major parts can be done in Java - it's been demonstrated by JikesRVM, and lots of experienced VM people point in that direction, even with a C/C++ core. I have no problem with that. How about we poll the VM candidates on who wants to help seed the project, ask them to do the paperwork, then we can get folks on board as committers and let them play in sandboxes (see below). Folks who do the work will then get to decide the future direction. We don't have to make the technical decision now before the committers are on board. What do you think? I don't see what we gain. We want to create *our design*, not make frankenVM. The point of starting with a small seed C/C++ kernel is to get the bootstrap and intrinsics support that *any* VM will need, pure C, pure Java, or mixed. Our discussions will point to where we have to refactor. On top of that, we build what we decide to build, not what we find out there, unless what we find out there is what we designed for. geir Steve, As a mentor, i agree with you whole heartedly. How do we go about this process of designing the core for harmony? Could we say strip down say JamVM/JCVM to create a bootstrapper (OS dependent stuff ONLY) for a stripped down JikesRVM in our sandbox to illustrate the validity of writing the almost the whole JVM in java? [Nothing like working code to get juices flowing]. My problem is that i haven't done this (writing a JVM) before, so am itching to do something that will help me understand better the problems/challenges involved and help me on deciding what to look for in the other existing VM's that we can leverage/use. Thanks, dims On 5/23/05, Steve Blackburn [EMAIL PROTECTED] wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is not the case Geir.
Show and tell
Credit to Steve for this idea : W/o having to drag code here to the ASF, can we try to summarize what the existing serious VM implementations that are out here did well, and not so well?I'm sure we can learn something from each, and would be nice if someone w/ a clue (i.e. involved in the VM itself) would report to save us the time :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
