[modules] big picture

[Steve Blackburn <St...@anu.edu.au>]

The discussion on JIT/classloader interfaces is encouraging.

I think it would be good to think a bit more about the higher level
design and get some more consensus on that.  So here are a few
thoughts.  These are very abstract and I am deliberatly not addressing
issue of language or API design.  I just want to provoke thought on
what the key concerns are, and how they inter-relate.

The following are pretty clearly first class modules:

  core  VM core
    mm  Memory management (GC etc)
  exec  Execution engine (JIT, interpreter, adaptive policies)
   lib  Class libraries

My guess is that the core is something that in the end Harmony will
write from scratch (perhaps based on something existing), whereas the
other three are distinct modules which in the first instance may be
existing implementations: Classpath, MMTk, StarJIT, Jikes RVM's
compilation subsystem etc.

There are other modules which may either be a) first class modules, or
b) sub-modules, but either way probably should be pluggable
(sub)modules. Here are a few that come to mind...

   exec.jit         Compiler instances
   exec.iterpreter  Interpreter instances

   core.scheduler   Threading and scheduling
   core.object      Object model
   core.classloader Class loader
   core.os          Operating system services


Thoughts?

--Steve

Re: [modules] big picture

["Geir Magnusson Jr." <ge...@apache.org>]

On Jun 25, 2005, at 2:13 PM, Steve Blackburn wrote:

> Geir Magnusson Jr. wrote:
>
>
>> What is a sensical way to modularize the rest?
>>
>
> Key to the approach is precisely that we need not introspect within  
> modules which we will not (initially) be implementing.  Thus we  
> need not concern ourselves with the internal structure of the  
> execution engine, or the memory manager if these are modules we  
> plan to leverage from elsewhere.
>
> If we focus on getting a core built quickly, then what matters   
> most is a) the interfaces between the core and other modules, and  
> b) the internal modular structure of the core.
>
> I think we'd all really like to see a core begin to take shape.   
> Understanding its internal structure and its relationship to the  
> outside world is the very first step.
>

I was really thinking about the classlibrary when I wrote that line,  
and then started doodling on the internals :)

So , the classlib...

geir

> --Steve
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [modules] big picture

[Steve Blackburn <St...@anu.edu.au>]

Geir Magnusson Jr. wrote:

> What is a sensical way to modularize the rest?

Key to the approach is precisely that we need not introspect within 
modules which we will not (initially) be implementing.  Thus we need not 
concern ourselves with the internal structure of the execution engine, 
or the memory manager if these are modules we plan to leverage from 
elsewhere.

If we focus on getting a core built quickly, then what matters  most is 
a) the interfaces between the core and other modules, and b) the 
internal modular structure of the core.

I think we'd all really like to see a core begin to take shape.  
Understanding its internal structure and its relationship to the outside 
world is the very first step.

--Steve

Re: [modules] big picture

["Geir Magnusson Jr." <ge...@apache.org>]

On Jun 25, 2005, at 4:48 AM, Steve Blackburn wrote:

[SNIP]

>
> The following are pretty clearly first class modules:
>
>  core  VM core
>    mm  Memory management (GC etc)
>  exec  Execution engine (JIT, interpreter, adaptive policies)
>   lib  Class libraries

[SNIP]

> There are other modules which may either be a) first class modules, or
> b) sub-modules, but either way probably should be pluggable
> (sub)modules. Here are a few that come to mind...
>
>   exec.jit         Compiler instances
>   exec.iterpreter  Interpreter instances
>
>   core.scheduler   Threading and scheduling
>   core.object      Object model
>   core.classloader Class loader
>   core.os          Operating system services
>
>
> Thoughts?

What is a sensical way to modularize the rest? Guessing more :

core.scheduler
core.object
core.classloader
core.so
core.?

mm.objectAllocation
mm.GC
mm.?

exec.jit
exec.jit.compiler
exec.jit.compiler.static
exec.jit.compiler.dynamic
exec.interpreter
exec.?

lib.?

I know that for things outside of Harmony proper like GNU Classpath  
as a class library implementation, we'd have to badger, cajole, and  
do the work, but it's worth trying to come to a complete model.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org