[arch] JFM modular structure was: Re: [arch] The Third Way : C/C++ and Java and lets go forward

[Dan Lydick <dl...@earthlink.net>]

> [Original Message]
> From: Weldon Washburn <we...@gmail.com>
> To: <ha...@incubator.apache.org>
> Date: 5/24/05 4:51:16 PM
> Subject: Re: [arch] The Third Way : C/C++ and Java and lets go forward
>
> On 5/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >=20
> > On May 23, 2005, at 8:23 PM, Steve Blackburn wrote:
> >=20
> > >> Lets get moving.  Comments?
> > >>
... snip...
> 
> 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


I think if we gear our environment toward
GNU Classpath, probably with a "legal-stuff"
wrapper, as has been suggested, then we will
maximize its current potential and learn its
foibles.  With this experience, we can go in
and add-- even extend existing-- functionality
to meet Harmony needs.

For boot classes, etc., we will probably have
all our own stuff due to our chosen design
constraints, and I would not guess that
they supply this anyway.

> 
> 1.6) Platform Accessors
> 
> 1.7) VM Accessors
> 
> 1.8) VM Core (the hub that glues all the above modules together)
> =20
> 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
> 


Dan Lydick