harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date Tue, 24 May 2005 21:51:12 GMT
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
> 
> 
>

Mime
View raw message