harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date Tue, 24 May 2005 22:37:17 GMT
updated wiki with this list - http://wiki.apache.org/harmony/HarmonyArchitecture

On 5/24/05, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 5/23/05, Geir Magnusson Jr. <geirm@apache.org> 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
> > geirm@apache.org
> >
> >
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message