Re: [arch] The Third Way : C/C++ and Java and lets go forward
On May 25, 2005, at 7:06 AM, netSQL wrote: Geir Magnusson Jr. wrote: both C/C++ and Java in this effort. Good thought. Lets consider this one step further for holly grail of Cross Platform: Consider C# (Mono w/ GTK#) and XPCom (Firefox Xross Platform objects) instaed of C/C++? ( I am sick of C/C++ and even Apple Objective C) Sort of Start w/ what we have on Fedora4, Eclipse(GTK2 native I belive in SWT) and Tomcat work on it w/ Classpath+GCJ. Then get this idea http://www.omnicore.com/xdevelop_comparison.htm (look at langs) and this Novell idea (look at langs) http://www.mono-project.com/ Plans . ( and http://www.ikvm.net - Java deployed on CLI) I spend a good portion of my few spare cycles pondering C# and Mono. I don't have enough of them to have reached any intelligent conclusion, though :) And related croos platform sucessfull efort is http:// wiki.mozilla.org/Gecko:SDK (Works great on Cocoa Mac, Active X, etc.; but this is a C/C++. It's a bit hard to work w/ make and pointers after Ant and GC), re-implement in both Java and ANSI C#. (more on C/C++ GRE, etc. http://www.mozilla.org/projects/embedding/faq.html, such as Geko/GTK + api. Even look at Apache http://httpd.apache.org/cli synergy, and iBatis Java and .NET ) So, what I am saying, a cross platform byte-code and CLI (not native w/ inspiration from XPCom)! Well, the pros will have to weigh in, but I'm concerned that you'd need a translation step from java bytecode to xplatform byte-code for everything, and then do your optimization and execution there. I don't know the penalty for that. I assume that IKVM at least can tell us how well that goes. So if you buy that, what's the compass? Here is what a simple PetStore(s) should bein Haromony XP: * http://www.eclipse.org/articles/Article-SWT-browser-widget/ browser.html * http://primates.ximian.com/~edasque/projects/Tutorial/glade2.html - I can make in Java via ikvm.net. Maybe target a sample browser app in ANSI C# (nothing evil about ANSI) and Java. Runtime can be bytecode, but somone could port to cross platform CLI. Summary: pick up where SWT / GCJ / Classpath are and have an eye on C#, steping over C++. Well, I think that wrt trying to eliminate C++ and C, you've just moved the problem elsewhere - because we'll still need a set of portable intrinsics and bootstrapper, and C++/C are natural candidates. That said, I would assume that properly architected, you could follow the same pattern and build in the framework we devise a CLI using the same techniques in C# used in Java. I think that's interesting, and certainly would build a larger community, but my personal interest is a compatible implementation of J2SE. Why that as focus? - Eclipse already WORKS and can and does ship w/ Linux distro (a MAJOR Harmony goal). - It's sufficiently chalanging, if the browser widget and application work XP, the text box, radio buttons is no problem. :-) (And somone down the road can write a full browser w/ Rino in Hramony) - I think that Mono browser and SWT browser are similar. Come up w/ ANSI and Java TCK way to implement. The sf.net motto is: do one thing and do it well, and I see all these things as convergence. .V (ot: I think I posted 1st on Java coming w/ FC4 that had a hand in kicking this off ;) -- 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: I spend a good portion of my few spare cycles pondering C# and Mono. I don't have enough of them to have reached any intelligent conclusion, though :) I am an (mainly Java) application's developer. When I develop one, I want to be able to deploy to Windoze users also. If I can compile my Java app to ANSI CLI p-code, it's a lot easier to deploy to Windows, since then there is no need for me to deploy ANY other run time, so I just ship my application. So it's a smaller too. (How I get this to work w/ WebStart... I duno YET! I assume Suse will have CLI runtime built in also). This way Harmiony may not need to have a run-time for Windowze, if it moves up the food chain and only emits p-code. I wrote some GTK# (sharp) apps, and they are fine. Well, I think that wrt trying to eliminate C++ and C, you've just moved the problem elsewhere - because we'll still need a set of portable intrinsics and bootstrapper, and C++/C are natural candidates. That said, I would assume that properly architected, you could follow the same pattern and build in the framework we devise a CLI using the same techniques in C# used in Java. I think that's interesting, and certainly would build a larger community, but my personal interest is a compatible implementation of J2SE. Yes, must be compatible! (this way if somone OS has Java-compatible JRE on it, I do not have to deploy the JRE. I would only deploy Harmony JRE if they do not have one. X-Box/PlayStation + OpenGL for our 3D needs ;-). If Sun/JRockit /Apple cover it, not a huge need, unless HW manafuctures want a better license ) Yes, I wish to minimize C/C++. Yuck. I used to teach both, those brain cells now invoke gag reflex. The native part is for run time, I have to remind self. I listed people that solve cross platform development(Ex: Geko GTK+, OpenGL(like SWT). The HTTP cross platform C is in wrong direction for us, it does not touch GUI, and bolting it on I predict would be a blind alley). Include a dll, .so and Cocoa libraries to be called via JNI, like SWT does. Did I usee enought acryonyms? Is there any more chances of haveing people that did Eclipse 3.16 on FC4 join Harmony in some way? .V
Re: [arch] The Third Way : C/C++ and Java and lets go forward
On 5/26/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Well, I think that wrt trying to eliminate C++ and C, you've just moved the problem elsewhere - because we'll still need a set of portable intrinsics and bootstrapper, and C++/C are natural candidates. That said, I would assume that properly architected, you could follow the same pattern and build in the framework we devise a CLI using the same techniques in C# used in Java. Yes. I agree. Even though its a non-goal, a good Harmony framework will also allow someone to add support for CLI application binaries. Note that the language an app is written in and the language(s) the VM is written in are independent. In other words, you can write a VM in Java that supports C# applications. Several years back we actually extended ORP to also run ECMA CLI. There are many common parts between a JVM and a .NET VM. Some of the issues were described in the Intel Technical Journal. See http://www.intel.com/technology/itj/2003/volume07issue01/art01_orp/p04_overview.htm I think that's interesting, and certainly would build a larger community, but my personal interest is a compatible implementation of J2SE.
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Archie Cobbs wrote: Nick Lothian wrote: According to http://www.csc.uvic.ca/~csc586a/Ass1.pdf JamVm lacks a bytecode verifier, too. Seems like most O/S VM's don't have one (including JC)... Gcj, leading the way, has two, or three by now :) Kaffe and CacaoJVM also have their own implementations, and JikesRVM as well, afaik. The plan for Kaffe is to merge in the gcjx verifier, and try to standardise on a commonly maintained verifier component, to make sure we fix the security issues once, instead of fixing them everywhere:) cheers, dalibor topic
Re: Bootstrapping community (Re: [arch] The Third Way : C/C++ and Java and lets go forward)
we are talking cross-purposes...i can't keep up with all the traffic. Are u sure, you haven't missed a nugget of information here and there? Am not saying that you should not pick Jam. Pick jam, but there are others who are willing to help and willing to write code and have contributions to bring in. *PLEASE* bring them in sooner than later. You know how bloody long it takes us to do the paperwork and get the infrastructure work done. Let's have the discussions on the mailing list. Document them say using java interfaces in SVN. Put up information on the wiki to back up the discussions. Let folks write some non-trivial code that is needed eventually but does not hinder your kernel work/discussions. For example, someone was going to write a javac wrapper for jdt. How do know which pieces of information on the mailing list you considered for taking a decision. and someone may use a totally different set of points made on the mailing list for taking the opposite decision. We need to document those in the design docs and/or wiki. Call me today and we can chat a bit more. thanks, dims On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 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
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 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. I very much resonate with Peter. Peter and I (and Leo) have scars all over out virtual bodies for the years of journey in Apache Avalon, where we traded architectural correctness over community wisdom. Failing miserably. The Avalon Project went down in flames. The simple technical disagreements became poisonous (and clever) personal attacks, in order to undermine the technical opponents and convince the community of the value of their position. Experienced Apache members and board directors spent years dealing with the social fallout of that project. It took 2 years for the ASF to kill avalon. If you ask all the participants, they will never go back. They know now how to accept disagreement, but more, how the 'perfect architecture' is a holy grail. Do the simplest thing that can possibly work for you and move on, the community is an incredibly powerful engine, it's better to learn how to use it than not. Now Avalon is dead and nobody is missing it. For a lot of us, it's a monument to the death of the old software engineering school applied to open development. A mythical land. A place that so many want to see existing that are willing to sacrifice a lot for it... but it nevertheless can't be reached, just like the real Avalon, King Arthur's tomb. I am the one who proposed Avalon, in 1998, with the intention of creating a 'kernel' for servers (before OSGi, before jboss mbeans, before geronimo's mbeans). I am the one who worked thru to kill it: despite the great deal of technological advancement that was
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Peter Donald 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 ... I have no problem with that.. with a project like this everyone has to accept that creative destruction will happen and not be afraid to alter cherised paradigms along the way. If taking the check in an existing VM and start hacking on it approach then probably JC is as good a candidate as any. 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. That's a good idea... I've made a small start.. http://wiki.apache.org/harmony/JVM_Implementation_Ideas -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Archie Cobbs wrote: That's a good idea... I've made a small start.. http://wiki.apache.org/harmony/JVM_Implementation_Ideas Excellent! --Steve
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Weldon Washburn wrote: In response to Geir's request, below is a first cut at a simple high-level modular structure: 1.1) Execution Modules Execution Manager Execution Engine Code generator Profile Collector 1.2) GC 1.3) Threading/sync Manager 1.4) Platform Portability Layer (OS and HW) 1.5) Class Libraries 1.6) Platform Accessors 1.7) VM Accessors 1.8) VM Core (the hub that glues all the above modules together) Others I can think of... :-) - JNI native interface module - JNI invocation interface module - Global/local references manager - Reflection manager (i.e., used by reflection native code) - Invocation manager - required to dynamically invoke methods from within the VM itself - Exception manager - can unwind stacks to throw exceptions - Bootstrapper - code to get the VM started - Resolver - performs field, class, method resolution - Verifier - Class initializer - invokes clinit's - Boot loader - the bootstrap class loader (reads ZIP files, etc) - Class deriver - defines runtime types (including array types) - Native library manager - dlopen()'s native libs, finds functions - Properties manager - sets system properties (e.g., java.vm.name). - String manager - converts between String - char *utf8; interning - Memory allocator - allocator for non-Java-heap memory - Finalizer module -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [arch] The Third Way : C/C++ and Java and lets go forward
updated wiki with this list - http://wiki.apache.org/harmony/HarmonyArchitecture On 5/24/05, Weldon Washburn [EMAIL PROTECTED] wrote: On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 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 In response to Geir's request, below is a first cut at a simple high-level modular structure: 1.1) Execution Modules Execution Manager Execution Engine Code generator Profile Collector 1.2) GC 1.3) Threading/sync Manager 1.4) Platform Portability Layer (OS and HW) 1.5) Class Libraries 1.6) Platform Accessors 1.7) VM Accessors 1.8) VM Core (the hub that glues all the above modules together) How about starting a new thread titled [Modules Interfaces] to discuss a) the definition of the JVM's modules and b) what the interface APIs look like? -- Weldon 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
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: [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
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] 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] 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] 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] 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.
