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 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] > > > > > > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
