harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From usman bashir <grip...@gmail.com>
Subject Re: JIRA and SVN
Date Sat, 21 May 2005 08:07:35 GMT
These are good thikning and i have few things more to add up.
 first i think it will be better that we select a base architecture that is 
completely based upon harmony rather then acquiring from other sides. then 
what we can do ,we can took one two or even three VMS and incoperate them 
with different target environments (i mean embeded, dektop,server) it will 
help us to also seee the performance issues but also allow us to work in 
parrallel in different areas.
 and now the question is how it could be done, one thing i m sure that we 
have guys from different enviornments like some from embeded culture and 
some from tradationals so we should split the work according their nature.
 altough it seem more vauge but i think we try to get few things on these 

 On 20 May 2005 17:54:11 -0600, Tom Tromey <tromey@redhat.com> wrote: 
> >>>>> "Geir" == Geir Magnusson <geirm@apache.org> writes:
> Geir> In the meantime, any comments on architectures of some of the VMs?
> Geir> I'm interest in having a balanced amount of upfront design that
> Geir> prevents us from preventing participation from unexpected places in
> Geir> the future...
> This is too vague -- we don't know much about the unexpected. Plus,
> in most cases, the "core" part of the VM is simply not very important.
> There just isn't much code there -- JamVM is 20KLOC, anybody could
> comfortably rewrite this.
> Instead I think Harmony should look at 2, and possibly 3, use cases:
> 1. Server use, e.g., some J2EE thing.
> 2. Desktop / applet use.
> 3. Embedded use (maybe).
> For 1, the execution engine and GC is really crucial. This is an area
> where hotspot-like dynamic recompilation implementations shine, IMO.
> For 2, again IMO, a gcj-like shared library approach is probably more
> useful. This is especially true if you expect to run more than one
> program using a given library, since in this case you are talking
> about controlling memory costs of the user environment as a whole.
> For 3 ... "embedded" covers a lot of ground, but I wanted to emphasize
> size-critical applications. In this arena you sometimes see folks who
> care more about size than performance. This affects choice of
> execution engine.
> I think it is possible to work well in all 3 environments with a
> single VM source base (though perhaps with different compilations of
> it).
> I think one way to do this would be an LLVM-based approach. This
> would require LLVM improvements, but let's be very clear about this --
> *any* approach we take to get to #1 and #2 is going to require a lot
> of compiler hacking. First, JITs have to be upgraded over time.
> Second, even with JikesRVM I think we're talking about at least
> writing new ports and an infrastructure for debuggers.
> One nice thing about the LLVM approach is that, hopefully, we could
> leverage other people's work. This is one reason gcj has been as
> widely ported as it is; the core gcj developers hardly ever do any
> architecture-specific work but instead we just inherit it from GCC.
> Tom

Usman Bashir
Certified IBM XML Solution Developer 
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional 
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message