You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Steve Blackburn <St...@anu.edu.au> on 2005/05/13 07:23:34 UTC
Developing Harmony
I am going to stick my neck out and make a few concrete suggestions
for how the Harmony VM might be developed.
A few motivating goals:
o Focus on modular, interchangeable components
- exploit existing compilers, memory managers etc
- promote configurability (different components for different contexts)
- allow diversity in development approaches
- encourage large-scale contributions (here's a compiler)
o Bootstrap the project rapidly
- capture momentum
- seed the project with an existing VM-core (or cores)
o Design a clean core (or cores) from scratch
- do this concurrently with work on components in existing core/s
- the core should be lightweight
- multiple cores may make sense
- the needs of different contexts may require this
- competing approaches may be healthy
A concrete option:
1. Use two VMs as seeds
a) Jikes RVM is a possible candidate
. Focus energy on cleaning it up and modularizing it. This is
something we've already begun (see earlier post), but will
take a lot of work.
+ Get a very good optimizing compiler
+ Get an efficient and modular memory management toolkit
(MMTk)
- Need to deal with licensing issues and gain the consent of
the community (not insurmountable)
- Need hard work to achieve modularity goal for whole VM
b) Another very different VM (kaffe?)
. amenable to modularization
. amenable to other components (drop in MMTk?)
2. Leverage extensive experience to build new core/s
. Start with a clean slate
. Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
jnode,...)
. Work concurrently with above work on components in old core/s,
miminize loss of momentum, try to really think it through
carefully.
. May be sensible to develop more than one core
3. Develop new components
. Extract components from existing work, apply to new VM/s
. Develop new components from scratch
. Encourage porting of existing compilers etc into this framework
Alternative options:
o Start with just one seed
o There are many different ways... the above is indicative, not exclusive
OK. So I've stuck my neck out. The above is vague and very
ambitious, but those rough thoughts come out of a lot of experience
with VM design---not just mine but the experience of those who I've
been discussing this with and working with. A component based VM is
not trivial at all. I've not mentioned any of the vast complexity
that lies within a real VM. However, my experience with porting MMTk
across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
working on porting to jnode--Java) gives me hope!
Cheers,
--Steve
Re: Two seeds (Re: Developing Harmony)
Posted by Davanum Srinivas <da...@gmail.com>.
oops. operator error
(https://svn.sable.mcgill.ca/wsvn/sable/?rev=1732&sc=1) threw me off.
SableVM does not use MMTk. But still....
-- dims
On 5/13/05, Davanum Srinivas <da...@gmail.com> wrote:
> Steve,
>
> This is great!!! I love the idea of using JikesRVM and one another JVM
> (hey SableVM already uses MMTk, Kaffe's license is too difficult -
> though not impossible - to change because TransVirtual is no more).
>
> thanks,
> dims
>
> On 5/13/05, Steve Blackburn <St...@anu.edu.au> wrote:
> > I am going to stick my neck out and make a few concrete suggestions
> > for how the Harmony VM might be developed.
> >
> > A few motivating goals:
> >
> > o Focus on modular, interchangeable components
> > - exploit existing compilers, memory managers etc
> > - promote configurability (different components for different contexts)
> > - allow diversity in development approaches
> > - encourage large-scale contributions (here's a compiler)
> >
> > o Bootstrap the project rapidly
> > - capture momentum
> > - seed the project with an existing VM-core (or cores)
> >
> > o Design a clean core (or cores) from scratch
> > - do this concurrently with work on components in existing core/s
> > - the core should be lightweight
> > - multiple cores may make sense
> > - the needs of different contexts may require this
> > - competing approaches may be healthy
> >
> > A concrete option:
> >
> > 1. Use two VMs as seeds
> > a) Jikes RVM is a possible candidate
> > . Focus energy on cleaning it up and modularizing it. This is
> > something we've already begun (see earlier post), but will
> > take a lot of work.
> > + Get a very good optimizing compiler
> > + Get an efficient and modular memory management toolkit
> > (MMTk)
> > - Need to deal with licensing issues and gain the consent of
> > the community (not insurmountable)
> > - Need hard work to achieve modularity goal for whole VM
> >
> > b) Another very different VM (kaffe?)
> > . amenable to modularization
> > . amenable to other components (drop in MMTk?)
> >
> > 2. Leverage extensive experience to build new core/s
> > . Start with a clean slate
> > . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> > jnode,...)
> > . Work concurrently with above work on components in old core/s,
> > miminize loss of momentum, try to really think it through
> > carefully.
> > . May be sensible to develop more than one core
> >
> > 3. Develop new components
> > . Extract components from existing work, apply to new VM/s
> > . Develop new components from scratch
> > . Encourage porting of existing compilers etc into this framework
> >
> >
> > Alternative options:
> >
> > o Start with just one seed
> >
> > o There are many different ways... the above is indicative, not exclusive
> >
> >
> > OK. So I've stuck my neck out. The above is vague and very
> > ambitious, but those rough thoughts come out of a lot of experience
> > with VM design---not just mine but the experience of those who I've
> > been discussing this with and working with. A component based VM is
> > not trivial at all. I've not mentioned any of the vast complexity
> > that lies within a real VM. However, my experience with porting MMTk
> > across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> > working on porting to jnode--Java) gives me hope!
> >
> > Cheers,
> >
> > --Steve
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Two seeds (Re: Developing Harmony)
Posted by Davanum Srinivas <da...@gmail.com>.
Steve,
This is great!!! I love the idea of using JikesRVM and one another JVM
(hey SableVM already uses MMTk, Kaffe's license is too difficult -
though not impossible - to change because TransVirtual is no more).
thanks,
dims
On 5/13/05, Steve Blackburn <St...@anu.edu.au> wrote:
> I am going to stick my neck out and make a few concrete suggestions
> for how the Harmony VM might be developed.
>
> A few motivating goals:
>
> o Focus on modular, interchangeable components
> - exploit existing compilers, memory managers etc
> - promote configurability (different components for different contexts)
> - allow diversity in development approaches
> - encourage large-scale contributions (here's a compiler)
>
> o Bootstrap the project rapidly
> - capture momentum
> - seed the project with an existing VM-core (or cores)
>
> o Design a clean core (or cores) from scratch
> - do this concurrently with work on components in existing core/s
> - the core should be lightweight
> - multiple cores may make sense
> - the needs of different contexts may require this
> - competing approaches may be healthy
>
> A concrete option:
>
> 1. Use two VMs as seeds
> a) Jikes RVM is a possible candidate
> . Focus energy on cleaning it up and modularizing it. This is
> something we've already begun (see earlier post), but will
> take a lot of work.
> + Get a very good optimizing compiler
> + Get an efficient and modular memory management toolkit
> (MMTk)
> - Need to deal with licensing issues and gain the consent of
> the community (not insurmountable)
> - Need hard work to achieve modularity goal for whole VM
>
> b) Another very different VM (kaffe?)
> . amenable to modularization
> . amenable to other components (drop in MMTk?)
>
> 2. Leverage extensive experience to build new core/s
> . Start with a clean slate
> . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> jnode,...)
> . Work concurrently with above work on components in old core/s,
> miminize loss of momentum, try to really think it through
> carefully.
> . May be sensible to develop more than one core
>
> 3. Develop new components
> . Extract components from existing work, apply to new VM/s
> . Develop new components from scratch
> . Encourage porting of existing compilers etc into this framework
>
>
> Alternative options:
>
> o Start with just one seed
>
> o There are many different ways... the above is indicative, not exclusive
>
>
> OK. So I've stuck my neck out. The above is vague and very
> ambitious, but those rough thoughts come out of a lot of experience
> with VM design---not just mine but the experience of those who I've
> been discussing this with and working with. A component based VM is
> not trivial at all. I've not mentioned any of the vast complexity
> that lies within a real VM. However, my experience with porting MMTk
> across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> working on porting to jnode--Java) gives me hope!
>
> Cheers,
>
> --Steve
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Developing Harmony
Posted by Archie Cobbs <ar...@dellroad.org>.
Panagiotis Astithas wrote:
>> b) Another very different VM (kaffe?)
>> . amenable to modularization
>> . amenable to other components (drop in MMTk?)
>
> Of all the options presented so far, what I find most appealing is the
> combination of a VM in Java (like JikesRVM) and a WAT approach like gcj
> or jcvm. In a sense that Harmony could enable either usage scenario,
> more or less like gcj does now. Would you think that MMTk could be used
> in say jcvm? Archie, would that make sense?
Sure.. like someone pointed out, there are already lots of JVM cores
that fill various niches. So one of Harmony's possible strengths could
be its modularity & flexibility. Obviously, it would mean it's not the
fastest VM in every scenario (no VM is) but on the other hand it would
probably end up being the most popular anyway.
In any case, the VM core is only one piece of the puzzle, and if
Classpath is going to be used, then the entire core is basically
going to be swappable anyway. This would be a good thing :-)
The big quantity of work lies in (further) developing the
class libraries...
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Developing Harmony
Posted by Davanum Srinivas <da...@gmail.com>.
Panagiotis,
MMTk is being used in SableVM (i think!)
-- dims
On 5/13/05, Panagiotis Astithas <pa...@ebs.gr> wrote:
> Steve Blackburn wrote:
> > I am going to stick my neck out and make a few concrete suggestions
> > for how the Harmony VM might be developed.
> >
> > A few motivating goals:
> >
> > o Focus on modular, interchangeable components
> > - exploit existing compilers, memory managers etc
> > - promote configurability (different components for different contexts)
> > - allow diversity in development approaches
> > - encourage large-scale contributions (here's a compiler)
> >
> > o Bootstrap the project rapidly
> > - capture momentum
> > - seed the project with an existing VM-core (or cores)
> >
> > o Design a clean core (or cores) from scratch
> > - do this concurrently with work on components in existing core/s
> > - the core should be lightweight
> > - multiple cores may make sense
> > - the needs of different contexts may require this
> > - competing approaches may be healthy
> >
> > A concrete option:
> >
> > 1. Use two VMs as seeds
> > a) Jikes RVM is a possible candidate
> > . Focus energy on cleaning it up and modularizing it. This is
> > something we've already begun (see earlier post), but will
> > take a lot of work.
> > + Get a very good optimizing compiler
> > + Get an efficient and modular memory management toolkit
> > (MMTk)
> > - Need to deal with licensing issues and gain the consent of
> > the community (not insurmountable)
> > - Need hard work to achieve modularity goal for whole VM
>
> Could we interpret this as a positive response to Davanum Srinivas's
> request for a JVM donation to the project?
>
> > b) Another very different VM (kaffe?)
> > . amenable to modularization
> > . amenable to other components (drop in MMTk?)
>
> Of all the options presented so far, what I find most appealing is the
> combination of a VM in Java (like JikesRVM) and a WAT approach like gcj
> or jcvm. In a sense that Harmony could enable either usage scenario,
> more or less like gcj does now. Would you think that MMTk could be used
> in say jcvm? Archie, would that make sense?
>
> > 2. Leverage extensive experience to build new core/s
> > . Start with a clean slate
> > . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> > jnode,...)
> > . Work concurrently with above work on components in old core/s,
> > miminize loss of momentum, try to really think it through
> > carefully.
> > . May be sensible to develop more than one core
> >
> > 3. Develop new components
> > . Extract components from existing work, apply to new VM/s
> > . Develop new components from scratch
> > . Encourage porting of existing compilers etc into this framework
> >
> >
> > Alternative options:
> >
> > o Start with just one seed
> >
> > o There are many different ways... the above is indicative, not exclusive
> >
> >
> > OK. So I've stuck my neck out. The above is vague and very
> > ambitious, but those rough thoughts come out of a lot of experience
> > with VM design---not just mine but the experience of those who I've
> > been discussing this with and working with. A component based VM is
> > not trivial at all. I've not mentioned any of the vast complexity
> > that lies within a real VM. However, my experience with porting MMTk
> > across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> > working on porting to jnode--Java) gives me hope!
> >
> > Cheers,
> >
> > --Steve
>
> Cheers,
>
> Panagiotis
>
> --
> Panagiotis Astithas
> EBS, Electronic Business Systems Ltd.
> 18 Evgenidou Street, 115 25, Athens GREECE
> Phone: +30 210 674 7631
> Fax: +30 210 674 7601
> http://www.ebs.gr
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Third Way - implement the JVM in a new C/Java hybrid
Posted by Anthony Green <gr...@redhat.com>.
On Fri, 2005-05-13 at 14:25 +0100, David Griffiths wrote:
> I thought GCJ was a static compilation system?
Not quite. GCJ is an ahead-of-time (AOT) compiler for the Java
programming language. However, the GCJ runtime execution environment
supports all of the dynamic properties of the Java programming language
(run-time loading/linking/verification, reflection, all of the binary-
compatibility rules, etc) for both bytecode and AOT compiled code.
AG
Re: Third Way - implement the JVM in a new C/Java hybrid
Posted by Mohammed Nour <no...@gmail.com>.
On 5/13/05, Steve Heath <st...@gmail.com> wrote:
> I hadn't thought that to write a JIT compiler you're writing a native
> compiler for Java anyway, so you might as well use this to create your
> VM, obvious really!
>
> There's a certain beauty to creating the VM in the language it is
> there to interpret.
>
> It does suggest we want to write the JIT first, then use this as our
> compiler for generating the VM..?
>
> On 5/13/05, David Griffiths <da...@gmail.com> wrote:
> > I thought GCJ was a static compilation system? What I was thinking of
> > was fully dynamic JIT-style compilation. A lot of the problems with
> > using C as the implementation language stem from it's statically
> > compiled nature. Not to mention the craziness of having
> > platform-specific code generation and optimisation duplicated in both
> > the C compiler and the Java JIT. (Which admittedly GCJ avoids).
> >
> > Cheers,
> >
> > Dave
> >
> > On 5/13/05, Bob <ci...@earthlink.net> wrote:
> > > >
> > > > So why not invent a new language that is a kind of half way house
> > > > between C and Java?
This kind of language already exists, it is called the "D" language. I
dont know much about it but it has very nice features that are
combined from C\C++ and JAVA.
But the idea of implementing the JIT in JAVA sounds much more interesting.
> > >
> > > I think that GCJ gives you this "third way" already. And it comes with
> > > a GC, which once explicitly managed, could be used as the Harmony GC as
> > > well. (GCJ's GC has an older pedigree, I believe).
> > >
> > >
> >
>
Re: Third Way - implement the JVM in a new C/Java hybrid
Posted by Steve Heath <st...@gmail.com>.
I hadn't thought that to write a JIT compiler you're writing a native
compiler for Java anyway, so you might as well use this to create your
VM, obvious really!
There's a certain beauty to creating the VM in the language it is
there to interpret.
It does suggest we want to write the JIT first, then use this as our
compiler for generating the VM..?
On 5/13/05, David Griffiths <da...@gmail.com> wrote:
> I thought GCJ was a static compilation system? What I was thinking of
> was fully dynamic JIT-style compilation. A lot of the problems with
> using C as the implementation language stem from it's statically
> compiled nature. Not to mention the craziness of having
> platform-specific code generation and optimisation duplicated in both
> the C compiler and the Java JIT. (Which admittedly GCJ avoids).
>
> Cheers,
>
> Dave
>
> On 5/13/05, Bob <ci...@earthlink.net> wrote:
> > >
> > > So why not invent a new language that is a kind of half way house
> > > between C and Java?
> >
> > I think that GCJ gives you this "third way" already. And it comes with
> > a GC, which once explicitly managed, could be used as the Harmony GC as
> > well. (GCJ's GC has an older pedigree, I believe).
> >
> >
>
Re: Third Way - implement the JVM in a new C/Java hybrid
Posted by David Griffiths <da...@gmail.com>.
I thought GCJ was a static compilation system? What I was thinking of
was fully dynamic JIT-style compilation. A lot of the problems with
using C as the implementation language stem from it's statically
compiled nature. Not to mention the craziness of having
platform-specific code generation and optimisation duplicated in both
the C compiler and the Java JIT. (Which admittedly GCJ avoids).
Cheers,
Dave
On 5/13/05, Bob <ci...@earthlink.net> wrote:
> >
> > So why not invent a new language that is a kind of half way house
> > between C and Java?
>
> I think that GCJ gives you this "third way" already. And it comes with
> a GC, which once explicitly managed, could be used as the Harmony GC as
> well. (GCJ's GC has an older pedigree, I believe).
>
>
Re: Third Way - implement the JVM in a new C/Java hybrid
Posted by Bob <ci...@earthlink.net>.
>
> So why not invent a new language that is a kind of half way house
> between C and Java?
I think that GCJ gives you this "third way" already. And it comes with
a GC, which once explicitly managed, could be used as the Harmony GC as
well. (GCJ's GC has an older pedigree, I believe).
Third Way - implement the JVM in a new C/Java hybrid
Posted by David Griffiths <da...@gmail.com>.
No, but seriously. :) I agree that C sucks as a JVM implementation
language for lots of reasons: the Java/C impedance mismatch, the lack
of ability to aggressively inline (which will be a big issue if you
every try to achieve real modularity), poor trace/debug/profiling
ability (wouldn't it be nice to have a coherent view of where your
time was being spent?).
The idea of implementing it in Java sounds nice except for all the
tricks you have to do to get round the infinite recursion problem.
So why not invent a new language that is a kind of half way house
between C and Java? It will be dynamically compiled just like Java but
won't come with a lot of the other stuff like GC and threading.
Instead it will have raw access to the platform system calls. Plus
some kind of support for C style memory pointers. The same compilation
engine would compile both the JVM parts written in this language plus
suitable converted Java bytecode.
I don't think inventing the language and writing a parser for it is
the hard part (it's pretty much Java-- with a dash of C), the hard
part is doing the optimising back-ends for all the different
platforms. But you've got to do that anyway unless you go the GCJ
route.
If it's possible to write a JVM in Java (as has been demonstrated)
then it's surely even easier to implement it in a purpose built
language. Such a language might have other system programming type
uses. Lots of existing JNI code could be converted to it.
Well that's just another thought in case you were in danger of
reaching a consensus. :)
Cheers,
Dave
Re: Developing Harmony
Posted by Panagiotis Astithas <pa...@ebs.gr>.
Steve Blackburn wrote:
> I am going to stick my neck out and make a few concrete suggestions
> for how the Harmony VM might be developed.
>
> A few motivating goals:
>
> o Focus on modular, interchangeable components
> - exploit existing compilers, memory managers etc
> - promote configurability (different components for different contexts)
> - allow diversity in development approaches
> - encourage large-scale contributions (here's a compiler)
>
> o Bootstrap the project rapidly
> - capture momentum
> - seed the project with an existing VM-core (or cores)
>
> o Design a clean core (or cores) from scratch
> - do this concurrently with work on components in existing core/s
> - the core should be lightweight
> - multiple cores may make sense
> - the needs of different contexts may require this
> - competing approaches may be healthy
>
> A concrete option:
>
> 1. Use two VMs as seeds
> a) Jikes RVM is a possible candidate
> . Focus energy on cleaning it up and modularizing it. This is
> something we've already begun (see earlier post), but will
> take a lot of work.
> + Get a very good optimizing compiler
> + Get an efficient and modular memory management toolkit
> (MMTk)
> - Need to deal with licensing issues and gain the consent of
> the community (not insurmountable)
> - Need hard work to achieve modularity goal for whole VM
Could we interpret this as a positive response to Davanum Srinivas's
request for a JVM donation to the project?
> b) Another very different VM (kaffe?)
> . amenable to modularization
> . amenable to other components (drop in MMTk?)
Of all the options presented so far, what I find most appealing is the
combination of a VM in Java (like JikesRVM) and a WAT approach like gcj
or jcvm. In a sense that Harmony could enable either usage scenario,
more or less like gcj does now. Would you think that MMTk could be used
in say jcvm? Archie, would that make sense?
> 2. Leverage extensive experience to build new core/s
> . Start with a clean slate
> . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> jnode,...)
> . Work concurrently with above work on components in old core/s,
> miminize loss of momentum, try to really think it through
> carefully.
> . May be sensible to develop more than one core
>
> 3. Develop new components
> . Extract components from existing work, apply to new VM/s
> . Develop new components from scratch
> . Encourage porting of existing compilers etc into this framework
>
>
> Alternative options:
>
> o Start with just one seed
>
> o There are many different ways... the above is indicative, not exclusive
>
>
> OK. So I've stuck my neck out. The above is vague and very
> ambitious, but those rough thoughts come out of a lot of experience
> with VM design---not just mine but the experience of those who I've
> been discussing this with and working with. A component based VM is
> not trivial at all. I've not mentioned any of the vast complexity
> that lies within a real VM. However, my experience with porting MMTk
> across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> working on porting to jnode--Java) gives me hope!
>
> Cheers,
>
> --Steve
Cheers,
Panagiotis
--
Panagiotis Astithas
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601
http://www.ebs.gr
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 13, 2005, at 1:23 AM, Steve Blackburn wrote:
> I am going to stick my neck out and make a few concrete suggestions
> for how the Harmony VM might be developed.
>
> A few motivating goals:
>
> o Focus on modular, interchangeable components
> - exploit existing compilers, memory managers etc
> - promote configurability (different components for different
> contexts)
> - allow diversity in development approaches
> - encourage large-scale contributions (here's a compiler)
Yes - that was the goal :)
> o Bootstrap the project rapidly
> - capture momentum
> - seed the project with an existing VM-core (or cores)
>
That too :)
> o Design a clean core (or cores) from scratch
> - do this concurrently with work on components in existing core/s
> - the core should be lightweight
> - multiple cores may make sense
> - the needs of different contexts may require this
> - competing approaches may be healthy
>
Agreed. I'd like to see us start with *one* donation from someone
that won't mind us kicking it around and deciding what's wrong :) and
examining all the other VMs that we can. THen we either fix (because
I'm really lazy), or start again based on what we've learned from all
the others..
> A concrete option:
>
> 1. Use two VMs as seeds
> a) Jikes RVM is a possible candidate
> . Focus energy on cleaning it up and modularizing it. This is
> something we've already begun (see earlier post), but will
> take a lot of work.
> + Get a very good optimizing compiler
> + Get an efficient and modular memory management toolkit
> (MMTk)
> - Need to deal with licensing issues and gain the consent of
> the community (not insurmountable)
> - Need hard work to achieve modularity goal for whole VM
>
> b) Another very different VM (kaffe?)
> . amenable to modularization
> . amenable to other components (drop in MMTk?)
Well, Kaffe is certainly something we want to study and learn from,
but I'm not sure we can start with it - it's already a separate,
healthy project elsewhere!
>
> 2. Leverage extensive experience to build new core/s
> . Start with a clean slate
> . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> jnode,...)
> . Work concurrently with above work on components in old core/s,
> miminize loss of momentum, try to really think it through
> carefully.
> . May be sensible to develop more than one core
>
> 3. Develop new components
> . Extract components from existing work, apply to new VM/s
> . Develop new components from scratch
> . Encourage porting of existing compilers etc into this framework
>
>
> Alternative options:
>
> o Start with just one seed
>
> o There are many different ways... the above is indicative, not
> exclusive
>
>
> OK. So I've stuck my neck out. The above is vague and very
> ambitious, but those rough thoughts come out of a lot of experience
> with VM design---not just mine but the experience of those who I've
> been discussing this with and working with. A component based VM is
> not trivial at all. I've not mentioned any of the vast complexity
> that lies within a real VM. However, my experience with porting MMTk
> across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> working on porting to jnode--Java) gives me hope!
>
> Cheers,
>
> --Steve
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Nicolas Toper <nt...@gmail.com>.
Hi all,
I'm a Java programmer and a CS student at CNAM in France. I'm interested to
work in this project.
About the C vs C++, I'd suggest C for various reasons:
- C is simpler to learn/use than C++
- C++ memory footprint is usually bigger than C one
- C++ is good for mixing high level and low level systems. Here, we only
care for the low level one, since the high level might be done in "pure"
Java.
Just my piece of thoughts
nicolas
2005/5/16, Ben Laurie <be...@algroup.co.uk>:
>
> Tom Tromey wrote:
> >>>>>>"Steve" == Steve Blackburn <St...@anu.edu.au> writes:
> >
> >
> > Steve> I am going to stick my neck out and make a few concrete
> suggestions
> > Steve> for how the Harmony VM might be developed.
> >
> > Excellent post.
> >
> >
> > I would like to mention a different possibility:
> >
> > * Write a new, modular VM in C or C++
> > - Go through the interoperability list[1] and define internal
> > modules along these boundaries
> > - Pick 2-3 use cases as target environments. I suggest "small
> > embedded", "desktop application", and "j2ee server"
> > - Make good reference choices
> > * Use Classpath as the class library
> > * Port MMTk to C, or otherwise find a way to use it
>
> Or use it to test the "modular, in any language" concept.
>
> > * Use LLVM[2] as the JIT engine
>
> LLVM looks cool, but comes with a wholebunchastuff under different
> licenses embedded in it. A casual inspection suggests we can probably
> work around them, but a closer inspection would be required.
>
> > * Write an interpreter engine as well, for special situations (small
> > memory). Assuming Classpath proves to have an acceptable license,
> > which really IMNSHO is the only sane possibility, we can just copy
> > over the one from libgcj.
> >
> >
> > Drawbacks of this plan:
> >
> > * JikesRVM is further along, so longer time to "hello world"
> > * Everybody has to learn C++ (or C)
>
> I don't really buy this is a drawback, since whatever you choose,
> everybody'll have to learn it.
>
> It would be wrong to assume that everyone involved in this project is
> totally in love with Java :-)
>
> I'm pretty sure we want a framework in C/C++, whatever components are
> developed in.
>
> Question to the floor: if it had to be one of C and C++, which would you
> prefer?
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: Developing Harmony
Posted by Ozgur Akan <ak...@aiqa.com>.
Jónas Tryggvi Jóhannsson wrote:
>
>
>
> I think that we should go the Java way.. and I really hope that
> JikesRVM will be our starting point!
>
After reading more about Jikes "A JVM in Java" idea seems to be better
for me then it used to be. I am just anxious about the performance.
Whatever we do and how, we must create a fast JVM. Performance is
everything if Harmony will be used more than educational needs.
"Faster" is a magic word.
> As Mark Brooks says about implement the JVM in Java; "Eating our own
> dog food" has the benefit of forcing us to deal with optimization
> issues that we might otherwise sweep under the carpet.
>
> But I guess the language will just depend on who donates a JVM.
It can be Jikes, but we shall test it`s performance...
>
> - Jónas Tryggvi
>
Ozgur Akan
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 18, 2005, at 9:08 AM, Mark Brooks wrote:
>> But I guess the language will just depend on who donates a JVM.
>>
>> - Jónas Tryggvi
>>
>
> Since somebody(s) are in conversation with FSF about Classpath, has
> anyone started a conversation with IBM research about Jikes RVM?
> Just a prelimininary sort of "if we were interested what would be
> involved" sort of thing.
yes
>
> I think Geir has said that we are looking at jcvm as well since a
> list member has offered to donate it and place it under the apache
> license.
Well, (man, I just can't get away from licenses...) I think that we
might want to look at a few and discuss the differences, and then
decide if someone wishes to contribute, and what license issues have
to be dealt with.
If anyone has other candidates, lets hear about them. I myself are
looking for "small" ones so I can get up to speed easier...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Mark Brooks <jm...@hotmail.com>.
>But I guess the language will just depend on who donates a JVM.
>
>- Jónas Tryggvi
Since somebody(s) are in conversation with FSF about Classpath, has anyone
started a conversation with IBM research about Jikes RVM? Just a
prelimininary sort of "if we were interested what would be involved" sort of
thing.
I think Geir has said that we are looking at jcvm as well since a list
member has offered to donate it and place it under the apache license.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Developing Harmony
Posted by Jónas Tryggvi Jóhannsson <jo...@ru.is>.
Carlos Fernandez Sanz wrote:
> Jónas Tryggvi Jóhannsson wrote:
>
>>> Question to the floor: if it had to be one of C and C++, which would
>>> you prefer?
>>
>> I can't think of a single reason why C should be preferred over C++.
>> C can simply be viewed as a subset of C++, and as Java users we all
>
> This might be true for newbies but anyone who has used both knows that
> this assertion is very superficial.
> Using C or C++ is, among other things, a design decision.
Well, "beginner" might be the magic word here!
I've had to dig into the Linux code a couple of times when doing
research, and Linux is written in C in Object Oriented fashion. The
Linux code is so obscure for newcomers that they really can't understand
what is going on; all those function pointers that could be virtual
functions in C++ and lack of abstraction really hinders the research
community to participate in my opinion. (and more documentation would be
nice.. a simple wiki updated function by function by the guys that
implement them would be nice!)
In this project we really need the universities with us as they bring
fresh ideas and it would be really useful if they could implement some
of them! I feel that a couple of extra CPU cycles and memory should be
sacrificed so that more people can participate in the project. It
ensures that this project can keep up with new ideas, which in the end
will result in better performance than C gives us. Because of that we
should go with a more high level language.
I think that we should go the Java way.. and I really hope that JikesRVM
will be our starting point!
As Mark Brooks says about implement the JVM in Java; "Eating our own dog
food" has the benefit of forcing us to deal with optimization issues
that we might otherwise sweep under the carpet.
But I guess the language will just depend on who donates a JVM.
- Jónas Tryggvi
Re: Developing Harmony
Posted by Carlos Fernandez Sanz <cf...@nisupu.com>.
Jónas Tryggvi Jóhannsson wrote:
>
>> Question to the floor: if it had to be one of C and C++, which would
>> you prefer?
>
>
> I can't think of a single reason why C should be preferred over C++.
> C can simply be viewed as a subset of C++, and as Java users we all
This might be true for newbies but anyone who has used both knows that
this assertion is very superficial.
Using C or C++ is, among other things, a design decision.
Having said that, I'd say that the biggest advantage of C++ in this case
is its library. Are we going to use it to implement Java's? Are we going
to use boost?
Carlos.
Re: Developing Harmony
Posted by Mark Brooks <jm...@hotmail.com>.
>I can't think of a single reason why C should be preferred over C++.
>C can simply be viewed as a subset of C++
Not anymore, really. The current ISO standards for C and C++ have
eliminated the "C++ is only a superset" aspect. They really are different
languages.
Also, you CAN write C in an object-oriented style, as the GTK+ project
demonstrates.
However...
>I'm however very fond of the idea of writing the JVM in Java. I'm
>beginning to look into the JikesRVM and I really like the idea,
>especially as it is the language that everyone on this list is familiar
>with.
That would be my preference as well. "Eating our own dog food" has the
benefit of forcing us to deal with optimization issues that we might
otherwise sweep under the carpet through using a lower-level language. It
also introduces much more time debugging, fixing common errors, handling
threading through low-level APIs, etc, to use either C or C++, not to
mention that if we use C++, we would have to use a restricted subset of C++
to assure portability, and that will create its own headaches..
So I would support sticking with Java also.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Developing Harmony
Posted by Jónas Tryggvi Jóhannsson <jo...@ru.is>.
> Question to the floor: if it had to be one of C and C++, which would
> you prefer?
I can't think of a single reason why C should be preferred over C++.
C can simply be viewed as a subset of C++, and as Java users we all
appreciate object orientation and understand how it can be used to
simplify software and make it more readable. Writing C code in an object
oriented manner simply does not give the same level of abstraction C++
can provide.
I'm however very fond of the idea of writing the JVM in Java. I'm
beginning to look into the JikesRVM and I really like the idea,
especially as it is the language that everyone on this list is familiar
with. It would also maximize the quality of the tools that we will
provide, as we would be using them to develop our JVM.
- Jónas Tryggvi
Re: Developing Harmony
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Ben Laurie wrote:
> In any case, here I am with a platform that currently has no VM, but
> does have a C compiler. What do I do?
>
> In your world, I first port some other VM, then port Harmony. I don't
> understand why this is not harder?
The bootstrapping JVM does not need to be particularly fast nor
efficient. That comes when Harmony compiles itself on your platform.
Re: Developing Harmony
Posted by Steve Blackburn <St...@anu.edu.au>.
Tom Tromey wrote:
> One thing I don't know, that I would like to know, is what parts of
>
>the java class libraries are used by the JikesRVM core. How big is
>the minimal installed image? What runtime facilities of Java are
>assumed by the core? E.g., does the JIT itself rely crucially on
>exception handling? Garbage collection?
>
>The reason I ask is that I'm curious about how minimal a system can be
>made with JikesRVM.
>
>
I think this is a very good question.
The very short answer is that, as it stands, Jikes RVM is not
lightweight. The interesting question is how much of this is intrinsic
and how much of this is an artifact of its explicit focus from inception
on server applications, high performance and scalability.
I think an indepth answer will take a bit of research. Some quick
observations that may help...
. MMTk has pretty minimal dependencies (it does not depend on GC,
exception handling, or any extenal feature or library that could
concievably call new(), for example!)
. The opt compiler is a large non-trivial piece of Java code written in
a more normal style. It probably has a similar level of dependencies to
other large complex optimizing compilers written in Java. It most
certainly depends on GC (it generates lots of small objects), and it
certainly depends on exception handling (if it fails for whatever
reason, it falls back to the baseline compiler).
. The opt compiler would not be appropriate for a lightweight VM in your
cell phone or whatever.
. Jikes RVM can run without the opt compiler.
Back to the development model...
I think the above discussion illustrates very nicely why we want
componentization.
It also highlights why I would like the seeds motivate the development
of new cores, written from scratch to work with existing high value
components. I would love to see a new core for the Jikes RVM
components. I would like to see new cores learn some of the lessons of
OVM (second generation java-in-java).
I can also see that there may be an important role for gcj here....
The problem with a compiler is that new backends must be written for
every target architecture. This is not a big deal if you're targetting
a modest set, such as IA32, PPC, SPARC etc, but if you really want to be
as portable to just about anything, then you will probably need to
forego the JIT on such platforms. This is fine too, because you
probably don't really want a JIT on your cell phone. So I see a role
for a core with an interpreter, if only to support the goal of
maximizing portability. (As a side note, I am opposed to mixed
interpretation/compilation within a given VM core. Far simpler to have
a quick and dirty compiler used alongside your opt compiler).
If you want to write an interpreter, you will want to compile it (!),
and if your compiler is highly portable, then voila, you have a highly
portable execution engine (a lesson kaffe, sable and others have shown
very nicely by leveraging gcc).
Anyway, back to gcj...
It seems to me that gcj can have a key role here. If our interpreted
core is written in Java and compiled with gcj then we gain that high
degree of portability. There are lots of other good things to say about
gcj, but this is just one thought about how we can build a nice clean
small-footprint core in Java and retain our portability goals.
Cheers,
--Steve
Re: Developing Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Ben" == Ben Laurie <be...@algroup.co.uk> writes:
>> One answer is, cross-build the VM from another machine that it does
>> work on. This is one way people bring up GCC on a new machine as
>> well.
Ben> I'm going to stop beating on this dead horse: you'll be happy if we
Ben> can implement the VM in Java. I'll be happy if we can implement it in
Ben> C.
Ben> We'll both be happy if we can implement it in either.
I was just answering questions, not advocating a position. I really
don't care much about the implementation language; I care more about
some attributes of the result.
One thing I don't know, that I would like to know, is what parts of
the java class libraries are used by the JikesRVM core. How big is
the minimal installed image? What runtime facilities of Java are
assumed by the core? E.g., does the JIT itself rely crucially on
exception handling? Garbage collection?
The reason I ask is that I'm curious about how minimal a system can be
made with JikesRVM.
Tom
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Tom Tromey wrote:
>>>>>>"Ben" == Ben Laurie <be...@algroup.co.uk> writes:
>
>
> Ben> This has to be a VM that produces native code, right?
>
> Yes.
>
> Ben> In any case, here I am with a platform that currently has no VM, but
> Ben> does have a C compiler. What do I do?
>
> One answer is, cross-build the VM from another machine that it does
> work on. This is one way people bring up GCC on a new machine as
> well.
I'm going to stop beating on this dead horse: you'll be happy if we can
implement the VM in Java. I'll be happy if we can implement it in C.
We'll both be happy if we can implement it in either.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Ben" == Ben Laurie <be...@algroup.co.uk> writes:
Ben> This has to be a VM that produces native code, right?
Yes.
Ben> In any case, here I am with a platform that currently has no VM, but
Ben> does have a C compiler. What do I do?
One answer is, cross-build the VM from another machine that it does
work on. This is one way people bring up GCC on a new machine as
well.
Tom
Re: Developing Harmony
Posted by Peter Donald <pe...@realityforge.org>.
Ben Laurie wrote:
> This has to be a VM that produces native code, right?
>
> In any case, here I am with a platform that currently has no VM, but
> does have a C compiler. What do I do?
>
> In your world, I first port some other VM, then port Harmony. I don't
> understand why this is not harder?
Because the "other" VM can be a minimalistic interpreter which is much
easier to port/write. This "other" VM bootstraps the java VM and that
does the jitting and machine code generation etc. It seems that it is
generally easier to optimize this way (ie Jikes RVM inlining of mem
allocations).
I am hoping that this is what this project does - Take an interpreter
(maybe jcvm) to bootstrap something like jikes.
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Tom Tromey wrote:
>>>>>>"Ben" == Ben Laurie <be...@algroup.co.uk> writes:
>
>
>>>>I'm pretty sure we want a framework in C/C++, whatever components
>>>>are developed in.
>
>
>>>Umm. Why?
>
>
> Ben> So it can run everywhere.
>
> FWIW, writing a VM in java doesn't make this harder per se.
> In fact, in a way it is easier as you are already writing a compiler,
> so you don't need another one for your target.
>
> The way JikesRVM works, as I understand it, is that you bootstrap it
> on some other VM. This makes an image, which is just plain old
> executable code, which is the actual VM. Then you can run your java
> programs using this image.
This has to be a VM that produces native code, right?
In any case, here I am with a platform that currently has no VM, but
does have a C compiler. What do I do?
In your world, I first port some other VM, then port Harmony. I don't
understand why this is not harder?
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Ben" == Ben Laurie <be...@algroup.co.uk> writes:
>>> I'm pretty sure we want a framework in C/C++, whatever components
>>> are developed in.
>> Umm. Why?
Ben> So it can run everywhere.
FWIW, writing a VM in java doesn't make this harder per se.
In fact, in a way it is easier as you are already writing a compiler,
so you don't need another one for your target.
The way JikesRVM works, as I understand it, is that you bootstrap it
on some other VM. This makes an image, which is just plain old
executable code, which is the actual VM. Then you can run your java
programs using this image.
Once you have the infrastructure for this, setting it up for
cross-building (cross architecture or cross OS) is not theoretically
hard, merely a SMOP.
It looks like JikesRVM already has some support for this:
http://jikesrvm.sourceforge.net/userguide/HTML/userguide_8.html
Tom
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Steve Blackburn wrote:
> A quick recap on key points from my original post (below):
>
> . Focus on componentization
> . Use one or two existing VMs to bootstrap and drive effort to componentize
> . Concurrently develop new cores
>
> As far as I can tell the goal of componentization is widely accepted.
>
> I view the VM core as another component, one of the simplest, but most
> design critical. The model of componentization allows any component to
> be written in whatever language makes most sense.
>
> For the sake of momentum I advocate concurrently pushing
> componentization in one or more existing VM cores while developing new
> cores.
>
> In my experience our biggest challenge is going to be in getting
> componentization to work. We've pushed this hard with MMTk (getting it
> to plug into multiple VMs, across language boundaries), and since the MM
> is probably the most intricately connected component, that gives us hope.
> You may find it interesting to read the writeup of the ORP team's effort
> to port their GC & JIT to Rotor
> (http://www.jot.fm/issues/issue_2004_10/article3/index_html).
>
>> I'm pretty sure we want a framework in C/C++, whatever components are
>> developed in.
>
>
> Umm. Why?
So it can run everywhere.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Ricky Clarkson <ri...@gmail.com>.
Do we need the extra features of C++ for the low-level stuff that
Harmony needs to do? Java can provide the OO wrappers around things,
we don't need Java wrappers around C++ classes around C functions..
I don't think there's enough gain in using C++ to warrant the extra
complexity in its use. But that's just me.
On 16/05/05, Steve Blackburn <St...@anu.edu.au> wrote:
> A quick recap on key points from my original post (below):
>
> . Focus on componentization
> . Use one or two existing VMs to bootstrap and drive effort to componentize
> . Concurrently develop new cores
>
> As far as I can tell the goal of componentization is widely accepted.
>
> I view the VM core as another component, one of the simplest, but most
> design critical. The model of componentization allows any component to
> be written in whatever language makes most sense.
>
> For the sake of momentum I advocate concurrently pushing
> componentization in one or more existing VM cores while developing new
> cores.
>
> In my experience our biggest challenge is going to be in getting
> componentization to work. We've pushed this hard with MMTk (getting it
> to plug into multiple VMs, across language boundaries), and since the MM
> is probably the most intricately connected component, that gives us hope.
>
> You may find it interesting to read the writeup of the ORP team's effort
> to port their GC & JIT to Rotor
> (http://www.jot.fm/issues/issue_2004_10/article3/index_html).
>
> > I'm pretty sure we want a framework in C/C++, whatever components are
> > developed in.
>
> Umm. Why?
>
> --Steve
>
> My original post....
>
> I am going to stick my neck out and make a few concrete suggestions
> for how the Harmony VM might be developed.
>
> A few motivating goals:
>
> o Focus on modular, interchangeable components
> - exploit existing compilers, memory managers etc
> - promote configurability (different components for different contexts)
> - allow diversity in development approaches
> - encourage large-scale contributions (here's a compiler)
>
> o Bootstrap the project rapidly
> - capture momentum
> - seed the project with an existing VM-core (or cores)
>
> o Design a clean core (or cores) from scratch
> - do this concurrently with work on components in existing core/s
> - the core should be lightweight
> - multiple cores may make sense
> - the needs of different contexts may require this
> - competing approaches may be healthy
>
> A concrete option:
>
> 1. Use two VMs as seeds
> a) Jikes RVM is a possible candidate
> . Focus energy on cleaning it up and modularizing it. This is
> something we've already begun (see earlier post), but will
> take a lot of work.
> + Get a very good optimizing compiler
> + Get an efficient and modular memory management toolkit
> (MMTk)
> - Need to deal with licensing issues and gain the consent of
> the community (not insurmountable)
> - Need hard work to achieve modularity goal for whole VM
>
> b) Another very different VM (kaffe?)
> . amenable to modularization
> . amenable to other components (drop in MMTk?)
>
> 2. Leverage extensive experience to build new core/s
> . Start with a clean slate
> . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> jnode,...)
> . Work concurrently with above work on components in old core/s,
> miminize loss of momentum, try to really think it through
> carefully.
> . May be sensible to develop more than one core
>
> 3. Develop new components
> . Extract components from existing work, apply to new VM/s
> . Develop new components from scratch
> . Encourage porting of existing compilers etc into this framework
>
> Alternative options:
>
> o Start with just one seed
>
> o There are many different ways... the above is indicative, not exclusive
>
> OK. So I've stuck my neck out. The above is vague and very
> ambitious, but those rough thoughts come out of a lot of experience
> with VM design---not just mine but the experience of those who I've
> been discussing this with and working with. A component based VM is
> not trivial at all. I've not mentioned any of the vast complexity
> that lies within a real VM. However, my experience with porting MMTk
> across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> working on porting to jnode--Java) gives me hope!
>
> Cheers,
>
> --Steve
>
Re: Developing Harmony
Posted by Steve Blackburn <St...@anu.edu.au>.
A quick recap on key points from my original post (below):
. Focus on componentization
. Use one or two existing VMs to bootstrap and drive effort to componentize
. Concurrently develop new cores
As far as I can tell the goal of componentization is widely accepted.
I view the VM core as another component, one of the simplest, but most
design critical. The model of componentization allows any component to
be written in whatever language makes most sense.
For the sake of momentum I advocate concurrently pushing
componentization in one or more existing VM cores while developing new
cores.
In my experience our biggest challenge is going to be in getting
componentization to work. We've pushed this hard with MMTk (getting it
to plug into multiple VMs, across language boundaries), and since the MM
is probably the most intricately connected component, that gives us hope.
You may find it interesting to read the writeup of the ORP team's effort
to port their GC & JIT to Rotor
(http://www.jot.fm/issues/issue_2004_10/article3/index_html).
> I'm pretty sure we want a framework in C/C++, whatever components are
> developed in.
Umm. Why?
--Steve
My original post....
I am going to stick my neck out and make a few concrete suggestions
for how the Harmony VM might be developed.
A few motivating goals:
o Focus on modular, interchangeable components
- exploit existing compilers, memory managers etc
- promote configurability (different components for different contexts)
- allow diversity in development approaches
- encourage large-scale contributions (here's a compiler)
o Bootstrap the project rapidly
- capture momentum
- seed the project with an existing VM-core (or cores)
o Design a clean core (or cores) from scratch
- do this concurrently with work on components in existing core/s
- the core should be lightweight
- multiple cores may make sense
- the needs of different contexts may require this
- competing approaches may be healthy
A concrete option:
1. Use two VMs as seeds
a) Jikes RVM is a possible candidate
. Focus energy on cleaning it up and modularizing it. This is
something we've already begun (see earlier post), but will
take a lot of work.
+ Get a very good optimizing compiler
+ Get an efficient and modular memory management toolkit
(MMTk)
- Need to deal with licensing issues and gain the consent of
the community (not insurmountable)
- Need hard work to achieve modularity goal for whole VM
b) Another very different VM (kaffe?)
. amenable to modularization
. amenable to other components (drop in MMTk?)
2. Leverage extensive experience to build new core/s
. Start with a clean slate
. Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
jnode,...)
. Work concurrently with above work on components in old core/s,
miminize loss of momentum, try to really think it through
carefully.
. May be sensible to develop more than one core
3. Develop new components
. Extract components from existing work, apply to new VM/s
. Develop new components from scratch
. Encourage porting of existing compilers etc into this framework
Alternative options:
o Start with just one seed
o There are many different ways... the above is indicative, not exclusive
OK. So I've stuck my neck out. The above is vague and very
ambitious, but those rough thoughts come out of a lot of experience
with VM design---not just mine but the experience of those who I've
been discussing this with and working with. A component based VM is
not trivial at all. I've not mentioned any of the vast complexity
that lies within a real VM. However, my experience with porting MMTk
across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
working on porting to jnode--Java) gives me hope!
Cheers,
--Steve
Re: Developing Harmony
Posted by Graham Leggett <mi...@sharp.fm>.
Ben Laurie wrote:
> Question to the floor: if it had to be one of C and C++, which would you
> prefer?
My gut feel is to stick with C, for portability and for better code.
Perhaps I'm just jaded after sifting through too much shocking
commercial C++ code, I think C++ may mean we get bitten down the line.
Regards,
Graham
--
Re: Developing Harmony
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Jónas Tryggvi Jóhannsson wrote:
> Im however very fond of the idea of writing the JVM in Java. Im
> beginning to look into the JikesRVM and I really like the idea,
> especially as it is the language that everyone on this list is
> familiar with. It would also maximize the quality of the tools that we
> will provide, as we would be using them to develop our JVM.
The JNode project has a JVM which has a small microkernel, and where the
rest is written in Java. Their performance figures[1] shows it to be
comparable to the Sun HotSpot compiler.
Does my mails come through, by the way?
[1] http://jnode.sourceforge.net/portal/node/51
--
Thorbjørn
Re: Developing Harmony
Posted by Ahmed Saad <my...@gmail.com>.
ok a question... hope it's not that silly anyways... if you did the JVM in
java we would need to compile it (or part of it) to native code... wouldn't
that be a problem when porting to other platforms? (sorry guys if it's so
silly)
On 5/17/05, Ozgur Akan <ak...@aiqa.com> wrote:
>
> JVM in Java will be the slower then Sun`s JVM. C or C++ is a better
> choice.
>
> Ozgur Akan
>
> Jónas Tryggvi Jóhannsson wrote:
>
> >
> >> Question to the floor: if it had to be one of C and C++, which would
> >> you prefer?
> >
> >
> > I can´t think of a single reason why C should be preferred over C++,
> > as C can simply be viewed as a subset of C++. As Java users, all of us
> > appreciate object orientation and understand how it can be used to
> > simplify software and make it more readable. Writing C code in an
> > object oriented manner simply does not give the same level of
> > abstraction C++ can provide.
> >
> > Im however very fond of the idea of writing the JVM in Java. Im
> > beginning to look into the JikesRVM and I really like the idea,
> > especially as it is the language that everyone on this list is
> > familiar with. It would also maximize the quality of the tools that we
> > will provide, as we would be using them to develop our JVM.
> >
> > - Jónas Tryggvi
> >
>
>
Re: Developing Harmony
Posted by Weldon Washburn <we...@gmail.com>.
On 5/19/05, Ahmed Saad <my...@gmail.com> wrote:
> >Then, if the VM is written in Java it will be compiled to native code
> using,
> >for example, gcj?
> >or it will be compiled to byte code and will be interpreted by itself?
One could interpret the VM code but it would be too slow for many. A
better choice is to run the bytecode through a JIT or ahead of time
compiler then execute the machine code. This binary image could be
created at development time then distributed thus saving the end-user
time and confusion.
Yes, it is confusing. I am convinced that in the long term the JVM
and the underlying OS will merge and that 90+ percent of the
combination will be written in a type-safe language (either Java or
C#).
In the short term, I believe we should develop Harmony in C/C++ with a
migration path to a type-safe language (either ECMA CLI based or
Java.)
> >I'm a little bit confused about this topic
>
> same goes here
>
> On 5/18/05, Juan Leyva Delgado <ju...@educa.madrid.org> wrote:
> >
> > Then, if the VM is written in Java it will be compiled to native code
> > using,
> > for example, gcj?
> > or it will be compiled to byte code and will be interpreted by itself?
> >
> > I'm a little bit confused about this topic
> >
> > ----- Original Message -----
> > From: "Stefano Mazzocchi" <st...@apache.org>
> > To: <ha...@incubator.apache.org>
> > Sent: Wednesday, May 18, 2005 4:46 PM
> > Subject: Re: Developing Harmony
> >
> >
> > > Ozgur Akan wrote:
> > >> JVM in Java will be the slower then Sun`s JVM. C or C++ is a better
> > >> choice.
> > >
> > > You have to undertand that "written in Java" does *NOT* equate
> > necessarely
> > > as "will be run as interpreted bytecode".
> > >
> > > --
> > > Stefano.
> > >
> > >
> >
> >
>
>
Re: Developing Harmony
Posted by Ahmed Saad <my...@gmail.com>.
>Then, if the VM is written in Java it will be compiled to native code
using,
>for example, gcj?
>or it will be compiled to byte code and will be interpreted by itself?
>I'm a little bit confused about this topic
same goes here
On 5/18/05, Juan Leyva Delgado <ju...@educa.madrid.org> wrote:
>
> Then, if the VM is written in Java it will be compiled to native code
> using,
> for example, gcj?
> or it will be compiled to byte code and will be interpreted by itself?
>
> I'm a little bit confused about this topic
>
> ----- Original Message -----
> From: "Stefano Mazzocchi" <st...@apache.org>
> To: <ha...@incubator.apache.org>
> Sent: Wednesday, May 18, 2005 4:46 PM
> Subject: Re: Developing Harmony
>
>
> > Ozgur Akan wrote:
> >> JVM in Java will be the slower then Sun`s JVM. C or C++ is a better
> >> choice.
> >
> > You have to undertand that "written in Java" does *NOT* equate
> necessarely
> > as "will be run as interpreted bytecode".
> >
> > --
> > Stefano.
> >
> >
>
>
Re: Developing Harmony
Posted by Juan Leyva Delgado <ju...@educa.madrid.org>.
Then, if the VM is written in Java it will be compiled to native code using,
for example, gcj?
or it will be compiled to byte code and will be interpreted by itself?
I'm a little bit confused about this topic
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <ha...@incubator.apache.org>
Sent: Wednesday, May 18, 2005 4:46 PM
Subject: Re: Developing Harmony
> Ozgur Akan wrote:
>> JVM in Java will be the slower then Sun`s JVM. C or C++ is a better
>> choice.
>
> You have to undertand that "written in Java" does *NOT* equate necessarely
> as "will be run as interpreted bytecode".
>
> --
> Stefano.
>
>
Re: Developing Harmony
Posted by Raffaele Castagno <ra...@gmail.com>.
2005/5/18, Stefano Mazzocchi <st...@apache.org>:
>
> Ozgur Akan wrote:
> > JVM in Java will be the slower then Sun`s JVM. C or C++ is a better
> choice.
>
> You have to undertand that "written in Java" does *NOT* equate
> necessarely as "will be run as interpreted bytecode".
>
I agree...It should be possible to write an high performance java native
code compiler. Are the restriction imposed by the java compiler and the VM
wich cause java to be slow. One example is bound check..
Raffaele
RE: Developing Harmony
Posted by Renaud BECHADE <re...@numerix.com>.
GCJ can run native java (ahead of time) on almost any reasonably useful
platform, NOW. To my knowledge it does not support java "generics" nor, of
course, reflection. (I mean the class foo<bar> stuff[1], but I think this is
just some boxing/unboxing question in its most naïve implementation. Any
idea on how to convert Java5 bytecode to "abtract execution-wise equivalent"
java 1.4 bytecode? This might the fast path to get things done, at least
before reflection is considered [2])
That being said, if a "Java in Java" VM needed to be bootstrapped, this
would probably be a relatively reliable and "easily available everywhere"
platform, freely available, NOW, and not so slow. After all it runs Eclipse
and may be sometimes in the future the OO2 stuff (at least according to
openoffice.org
What about writing this "Harmony" VM as a plugin to the GCJ? (just like
psycho - specialization VM for python - is a plugin for the CPython
implementation)
Just my 2 yen worth ideas, so please excuse any naïve stances.
RB
[1] I am not sure about the correct wording. "Generics" is an old Ada83
term, after all.
[2] Plus the support libraries to write. Quite a good bunch of work IMHO...
-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: Wednesday, May 18, 2005 11:47 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Developing Harmony
Ozgur Akan wrote:
> JVM in Java will be the slower then Sun`s JVM. C or C++ is a better
choice.
You have to undertand that "written in Java" does *NOT* equate
necessarely as "will be run as interpreted bytecode".
--
Stefano.
Re: Developing Harmony
Posted by Stefano Mazzocchi <st...@apache.org>.
Ozgur Akan wrote:
> JVM in Java will be the slower then Sun`s JVM. C or C++ is a better choice.
You have to undertand that "written in Java" does *NOT* equate
necessarely as "will be run as interpreted bytecode".
--
Stefano.
Re: Developing Harmony
Posted by Ozgur Akan <ak...@aiqa.com>.
JVM in Java will be the slower then Sun`s JVM. C or C++ is a better choice.
Ozgur Akan
Jónas Tryggvi Jóhannsson wrote:
>
>> Question to the floor: if it had to be one of C and C++, which would
>> you prefer?
>
>
> I can´t think of a single reason why C should be preferred over C++,
> as C can simply be viewed as a subset of C++. As Java users, all of us
> appreciate object orientation and understand how it can be used to
> simplify software and make it more readable. Writing C code in an
> object oriented manner simply does not give the same level of
> abstraction C++ can provide.
>
> Im however very fond of the idea of writing the JVM in Java. Im
> beginning to look into the JikesRVM and I really like the idea,
> especially as it is the language that everyone on this list is
> familiar with. It would also maximize the quality of the tools that we
> will provide, as we would be using them to develop our JVM.
>
> - Jónas Tryggvi
>
Re: Developing Harmony
Posted by Stephan Michels <st...@gmail.com>.
On 5/16/05, Jónas Tryggvi Jóhannsson <jo...@ru.is> wrote:
>
> > Question to the floor: if it had to be one of C and C++, which would
> > you prefer?
>
> I can´t think of a single reason why C should be preferred over C++, as
> C can simply be viewed as a subset of C++. As Java users, all of us
> appreciate object orientation and understand how it can be used to
> simplify software and make it more readable. Writing C code in an object
> oriented manner simply does not give the same level of abstraction C++
> can provide.
>
> Im however very fond of the idea of writing the JVM in Java. Im
> beginning to look into the JikesRVM and I really like the idea,
> especially as it is the language that everyone on this list is familiar
> with. It would also maximize the quality of the tools that we will
> provide, as we would be using them to develop our JVM.
I have another point. The VM should be instrumentable, by JMX for example.
This could easly done if the VM uses Java.
I would prefer if the Harmony project uses JikesVM as base, create a native
app with GCJ. This way we could use C++ parts over CNI.
Stephan Michels.
Re: Developing Harmony
Posted by Ozgur Akan <ak...@aiqa.com>.
you are talking about Jikes ;)
usman bashir wrote:
> We shouldl design in such a way that , we should get some
>interfacing/bootstrapping issues in C (can be C++ but i think due to its
>direct linking to natives C will be prefered i can present more argo over it
>though ;) )
> and then come back to java again until we feel ctuck some where (though
>what my experiance suggest and i have looked it into the presented projects,
>we can get rid of those concerete walls if any one we have to have face in
>the running of time )
> so what i am saying i m summing it up
> write in java using C.
> java provides us all those features which we need to go to this road , from
>the management, maintianbility and other stuffs (i m not writting SE book
>though ha ha ha) u all knows better.
> so what u think comment ?
> On 5/18/05, Panagiotis Astithas <pa...@ebs.gr> wrote:
>
>
>
>
>
Re: Developing Harmony
Posted by usman bashir <gr...@gmail.com>.
We shouldl design in such a way that , we should get some
interfacing/bootstrapping issues in C (can be C++ but i think due to its
direct linking to natives C will be prefered i can present more argo over it
though ;) )
and then come back to java again until we feel ctuck some where (though
what my experiance suggest and i have looked it into the presented projects,
we can get rid of those concerete walls if any one we have to have face in
the running of time )
so what i am saying i m summing it up
write in java using C.
java provides us all those features which we need to go to this road , from
the management, maintianbility and other stuffs (i m not writting SE book
though ha ha ha) u all knows better.
so what u think comment ?
On 5/18/05, Panagiotis Astithas <pa...@ebs.gr> wrote:
>
> Ben Laurie wrote:
> > Mark Brooks wrote:
> >
> >>> C++, just C++, is a recipe for trouble. Most projects that use it
> >>> define a
> >>> subset to make development a less painfull talk. Usually operator
> >>> overloading, templates and virtual inheritance are discarded.
> >>>
> >>> Rodrigo
> >>
> >>
> >>
> >> Agreed. If the decision is to go with C++, it will need to be a
> >> subset of C++ for sanity. I still think that, at most, a minimal C
> >> kernel and the rest in Java is a better option.
> >>
> >>> > As I said before, don't assume we're all Java fans here. I'm far
> more
> >>> > familiar with C++ than I am with Java.
> >>>
> >>>> <snip>
> >>>
> >>>
> >>> >
> >>> > Ben.
> >>
> >>
> >>
> >> If you aren't a Java fan, why are you interested in Harmony? Or am I
> >> misinterpreting what you meant there?
> >
> >
> > Surely I don't have to rate Java as the best language for everything in
> > order to be interested in Harmony? I don't think HTTP or SSL are the
> > best ways to do things, either, but I've spent an enormous amount of
> > time on both of them.
> >
> > There's all sorts of reasons I'm interested in Harmony.
> >
> > a) I recently tried Eclipse, and discovered it removed a major source of
> > Java irritation (excessive amounts of redundant typing). In fact, I love
> > Eclipse. If only I could get it working on FreeBSD :-)
>
> Since the java/eclipse port is working fine, I assume you want to use it
> with another JVM than java/jdk14? If so, and since this is something I
> was contemplating these days, under which JVM would you want to use it?
> Kaffe? GCJ? JC? JikesRVM?
>
> --
> Panagiotis Astithas
> EBS, Electronic Business Systems Ltd.
> 18 Evgenidou Street, 115 25, Athens GREECE
> Phone: +30 210 674 7631
> Fax: +30 210 674 7601
> http://www.ebs.gr
>
--
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
Re: Developing Harmony
Posted by Panagiotis Astithas <pa...@ebs.gr>.
Ben Laurie wrote:
> Mark Brooks wrote:
>
>>> C++, just C++, is a recipe for trouble. Most projects that use it
>>> define a
>>> subset to make development a less painfull talk. Usually operator
>>> overloading, templates and virtual inheritance are discarded.
>>>
>>> Rodrigo
>>
>>
>>
>> Agreed. If the decision is to go with C++, it will need to be a
>> subset of C++ for sanity. I still think that, at most, a minimal C
>> kernel and the rest in Java is a better option.
>>
>>> > As I said before, don't assume we're all Java fans here. I'm far more
>>> > familiar with C++ than I am with Java.
>>>
>>>> <snip>
>>>
>>>
>>> >
>>> > Ben.
>>
>>
>>
>> If you aren't a Java fan, why are you interested in Harmony? Or am I
>> misinterpreting what you meant there?
>
>
> Surely I don't have to rate Java as the best language for everything in
> order to be interested in Harmony? I don't think HTTP or SSL are the
> best ways to do things, either, but I've spent an enormous amount of
> time on both of them.
>
> There's all sorts of reasons I'm interested in Harmony.
>
> a) I recently tried Eclipse, and discovered it removed a major source of
> Java irritation (excessive amounts of redundant typing). In fact, I love
> Eclipse. If only I could get it working on FreeBSD :-)
Since the java/eclipse port is working fine, I assume you want to use it
with another JVM than java/jdk14? If so, and since this is something I
was contemplating these days, under which JVM would you want to use it?
Kaffe? GCJ? JC? JikesRVM?
--
Panagiotis Astithas
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601
http://www.ebs.gr
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Paul Richards wrote:
>>a) I recently tried Eclipse, and discovered it removed a major source of
>>Java irritation (excessive amounts of redundant typing). In fact, I love
>>Eclipse. If only I could get it working on FreeBSD :-)
>
>
> The FreeBSD Eclipse port "just worked" for me.
Just goes to show that ports aren't as reliable as one might hope, then,
coz it didn't work for me. Repeatedly.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Paul Richards <pa...@originative.co.uk>.
> a) I recently tried Eclipse, and discovered it removed a major source of
> Java irritation (excessive amounts of redundant typing). In fact, I love
> Eclipse. If only I could get it working on FreeBSD :-)
The FreeBSD Eclipse port "just worked" for me.
--
Paul Richards
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Mark Brooks wrote:
>> C++, just C++, is a recipe for trouble. Most projects that use it
>> define a
>> subset to make development a less painfull talk. Usually operator
>> overloading, templates and virtual inheritance are discarded.
>>
>> Rodrigo
>
>
> Agreed. If the decision is to go with C++, it will need to be a subset
> of C++ for sanity. I still think that, at most, a minimal C kernel and
> the rest in Java is a better option.
>
>> > As I said before, don't assume we're all Java fans here. I'm far more
>> > familiar with C++ than I am with Java.
>>
>>> <snip>
>>
>> >
>> > Ben.
>
>
> If you aren't a Java fan, why are you interested in Harmony? Or am I
> misinterpreting what you meant there?
Surely I don't have to rate Java as the best language for everything in
order to be interested in Harmony? I don't think HTTP or SSL are the
best ways to do things, either, but I've spent an enormous amount of
time on both of them.
There's all sorts of reasons I'm interested in Harmony.
a) I recently tried Eclipse, and discovered it removed a major source of
Java irritation (excessive amounts of redundant typing). In fact, I love
Eclipse. If only I could get it working on FreeBSD :-)
b) I'm interested in capability-secure versions of popular languages.
Java is a popular language.
c) I'm interested in security generally.
d) I'm interested in compilers.
e) I'm interested in VMs.
f) I'm interested in modularity.
g) I'm interested in portability.
So, in summary, my interest is in the nuts and bolts of Harmony far more
than in writing things in Java.
That said, I do write things in Java :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Mark Brooks <jm...@hotmail.com>.
>C++, just C++, is a recipe for trouble. Most projects that use it define a
>subset to make development a less painfull talk. Usually operator
>overloading, templates and virtual inheritance are discarded.
>
>Rodrigo
Agreed. If the decision is to go with C++, it will need to be a subset of
C++ for sanity. I still think that, at most, a minimal C kernel and the
rest in Java is a better option.
> > As I said before, don't assume we're all Java fans here. I'm far more
> > familiar with C++ than I am with Java.
>><snip>
> >
> > Ben.
If you aren't a Java fan, why are you interested in Harmony? Or am I
misinterpreting what you meant there?
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Developing Harmony
Posted by Rodrigo Kumpera <ku...@gmail.com>.
C++, just C++, is a recipe for trouble. Most projects that use it define a
subset to make development a less painfull talk. Usually operator
overloading, templates and virtual inheritance are discarded.
Rodrigo
On 5/17/05, Ben Laurie <be...@algroup.co.uk> wrote:
>
> Jónas Tryggvi Jóhannsson wrote:
> >
> >> Question to the floor: if it had to be one of C and C++, which would
> >> you prefer?
> >
> >
> > I can´t think of a single reason why C should be preferred over C++,
> as
> > C can simply be viewed as a subset of C++.
>
> That sounds like a reason to me.
>
> > As Java users, all of us
> > appreciate object orientation and understand how it can be used to
> > simplify software and make it more readable. Writing C code in an object
> > oriented manner simply does not give the same level of abstraction C++
> > can provide.
>
> I agree. Many developers don't.
>
> > Im however very fond of the idea of writing the JVM in Java. Im
> > beginning to look into the JikesRVM and I really like the idea,
> > especially as it is the language that everyone on this list is familiar
> > with.
>
> As I said before, don't assume we're all Java fans here. I'm far more
> familiar with C++ than I am with Java.
>
> > It would also maximize the quality of the tools that we will
> > provide, as we would be using them to develop our JVM.
>
> Like I said, a framework that allows you to do this is definitely what I
> want to see. But it should also allow me to write the JVM in C.
>
> Is the Jikes licence one we can use?
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Jónas Tryggvi Jóhannsson wrote:
>
>> Question to the floor: if it had to be one of C and C++, which would
>> you prefer?
>
>
> I can´t think of a single reason why C should be preferred over C++,
as
> C can simply be viewed as a subset of C++.
That sounds like a reason to me.
> As Java users, all of us
> appreciate object orientation and understand how it can be used to
> simplify software and make it more readable. Writing C code in an object
> oriented manner simply does not give the same level of abstraction C++
> can provide.
I agree. Many developers don't.
> Im however very fond of the idea of writing the JVM in Java. Im
> beginning to look into the JikesRVM and I really like the idea,
> especially as it is the language that everyone on this list is familiar
> with.
As I said before, don't assume we're all Java fans here. I'm far more
familiar with C++ than I am with Java.
> It would also maximize the quality of the tools that we will
> provide, as we would be using them to develop our JVM.
Like I said, a framework that allows you to do this is definitely what I
want to see. But it should also allow me to write the JVM in C.
Is the Jikes licence one we can use?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Jónas Tryggvi Jóhannsson <jo...@ru.is>.
> Question to the floor: if it had to be one of C and C++, which would
> you prefer?
I can´t think of a single reason why C should be preferred over C++, as
C can simply be viewed as a subset of C++. As Java users, all of us
appreciate object orientation and understand how it can be used to
simplify software and make it more readable. Writing C code in an object
oriented manner simply does not give the same level of abstraction C++
can provide.
Im however very fond of the idea of writing the JVM in Java. Im
beginning to look into the JikesRVM and I really like the idea,
especially as it is the language that everyone on this list is familiar
with. It would also maximize the quality of the tools that we will
provide, as we would be using them to develop our JVM.
- Jónas Tryggvi
Re: Developing Harmony
Posted by Mark Brooks <jm...@hotmail.com>.
>Now don't go too crazy for my suggesting this, but why not pascal?
Which dialect? ISO or GPC? Free Pascal or Delphi? (and if Delphi, which
version) etc..
Ada95 is superior for most purposes to Pascal, is more standardized (there
is only one standard) and is also widely available. It also produces very
stable, reliable, maintainable applications, and has great standard thread
support. There are widely available free implementations. It has seen
heavy use in embedded and real-time applications (where many C/C++ compilers
don't cut the mustard and real-time Java is still ghosty) which by their
nature bear a strong resemblance to a VM and have a similar problem domain.
However, most people's exposure to Pascal is long ago and in an academic
context, at least here in the States. I think most schools here have used C
or C++, some have moved to Java, and there are some that avoid "business
languages" altogether, using stuff like Scheme. On the other hand, C, C++,
and Java are more likely to be known to the developer base that would be
interested in this project.
My comment is not intended to be a flame for the Pascal fans. I know that
Free Pascal has just come out with 2.0, and there are many people,
particularly in Europe, who cut their teeth on Pascal. If we are looking at
something outside the "C family" (i.e. C/C++/Java/C#) as an implementation
language, my opinion is that Pascal is not necessarily the best choice even
among imperitive programming languages. However, most open source
development centers around "C family" languages, and there is the issue of
critical mass as well as of technical suitability. I guess the answer for
me is that Pascal in the round doesn't really offer that much of an
advantage over using a "C family" language to set off the disadvantages.
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: Developing Harmony
Posted by Rodrigo Kumpera <ku...@gmail.com>.
If C/C++ is going to be used, the reference compiler is gcc. I don´t think
the pascal frontend of gcc is up to the others.
Rodrigo
On 5/17/05, Bryce Leo <li...@gmail.com> wrote:
>
> Now don't go too crazy for my suggesting this, but why not pascal? If
> we're considering C as it is this really isn't a terrible suggestion.
> I know it's fallen out of favor with most of you guys but it compiles
> quickly and supports a good number of operating systems and types of
> hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
> betting that you guys won't like it but I think the option should be
> listed.
>
> Opinions?
>
> ~Bryce Leo
>
> --Veritas Vos Liberabis--
>
Re: Developing Harmony
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
> Stefano Mazzocchi wrote:
>
>> Bryce Leo wrote:
>>
>>> Now don't go too crazy for my suggesting this, but why not pascal? If
>>> we're considering C as it is this really isn't a terrible suggestion.
>>> I know it's fallen out of favor with most of you guys but it compiles
>>> quickly and supports a good number of operating systems and types of
>>> hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
>>> betting that you guys won't like it but I think the option should be
>>> listed.
>>>
>>> Opinions?
>>
>>
>>
>> Can we stop this language madness thing, please?
>>
>> We are *NOT* going to be writing a JVM from scratch, we are open for
>> donations.
>
> Says who? If people here want to write a VM, are you going to stop them?
> I hope you wouldn't even try.
I'll discuss that when it happens ;-)
--
Stefano.
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> Bryce Leo wrote:
>
>> Now don't go too crazy for my suggesting this, but why not pascal? If
>> we're considering C as it is this really isn't a terrible suggestion.
>> I know it's fallen out of favor with most of you guys but it compiles
>> quickly and supports a good number of operating systems and types of
>> hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
>> betting that you guys won't like it but I think the option should be
>> listed.
>>
>> Opinions?
>
>
> Can we stop this language madness thing, please?
>
> We are *NOT* going to be writing a JVM from scratch, we are open for
> donations.
Says who? If people here want to write a VM, are you going to stop them?
I hope you wouldn't even try.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Dalibor Topic <ro...@kaffe.org>.
Rob Gonzalez wrote:
> - Kaffe is GPL and no one organization or person owns the copyright
> (as compared to GNU projects, for example), so it's basically
> impossible to re-license.
s/no one/no single/ :)
everyone owns the copyright to their own contributions, which is what
would make relicensing a pretty huge effort, as Kaffe has 9 years of
development history behind it.
thanksfully, other VMs have been offered, so we don't have to go through
that excercise :)
cheers,
dalibor topic
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 19, 2005, at 5:26 PM, Ian Darwin wrote:
>> AFAICT JC is the only real option on the table right now.
>>
>> - jc was donated under the apache license.
>>
>
>
>> since we're now officially in the incubator, can we check this
>> into an
>> apache SVN repository and get hacking at it?
>>
>
> MudgeVM is under an open license and should be looked at before you
> start
> committing stuff :-)
I'm looking at it. I'm trying to understand how it's architected.
geir
>
> Ian
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 20, 2005, at 2:55 AM, Rafal Lewczuk wrote:
> Hi,
>
> On 5/19/05, Ian Darwin <ia...@darwinsys.com> wrote:
>
>> MudgeVM is under an open license and should be looked at before
>> you start
>> committing stuff :-)
>>
>
>
> I've tried googling and freshmeating for 'MudgeVM' but couldn't
> find it.
> Can I ask for links ?
>
Look here :
http://www.mudge.nl/java/
> Thanks,
> rle
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Rafal Lewczuk <ra...@gmail.com>.
Hi,
On 5/19/05, Ian Darwin <ia...@darwinsys.com> wrote:
> MudgeVM is under an open license and should be looked at before you start
> committing stuff :-)
I've tried googling and freshmeating for 'MudgeVM' but couldn't find it.
Can I ask for links ?
Thanks,
rle
Re: Developing Harmony
Posted by Ian Darwin <ia...@darwinsys.com>.
> AFAICT JC is the only real option on the table right now.
>
> - jc was donated under the apache license.
> since we're now officially in the incubator, can we check this into an
> apache SVN repository and get hacking at it?
MudgeVM is under an open license and should be looked at before you start
committing stuff :-)
Ian
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 19, 2005, at 2:38 PM, Rob Gonzalez wrote:
>>> - jc (written in C)
>>> - jikes rvm (written in java)
>>>
>>
>> Between those two I'm on the side of jc becuase it should run faster
>> than jikes rvm, I don't know why it wouldn't. Though I don't know why
>> Kaffe isn't on the list.
>>
>
> AFAICT JC is the only real option on the table right now.
>
> - jc was donated under the apache license.
>
> - JikesRVM is CPL, so i don't believe it's automatically on the table
> without IBM's releasing a version under the apache license.
>
> - Kaffe is GPL and no one organization or person owns the copyright
> (as compared to GNU projects, for example), so it's basically
> impossible to re-license.
>
>
> since we're now officially in the incubator, can we check this into an
> apache SVN repository and get hacking at it?
No. I think it's really in our best interest to sort out our commit
policy before committing *any* code. (I still have fresh scars from
Geronimo, due to process, rather than actual issues. But process can
kill you...)
Expect an email after I land tomorrow, 12:40 EDT :)
>
>
> Regarding the x-platform & modularity goals; regardless of whether
> most of the VM itself is written in Java, C, or whatever, having a
> small bootloading VM layer that instantiates the rest of the VM --
> again, a la JikesRVM -- is probably a good design decision and
> something that can be worked on immediately; not that I'm
> volunteering for that myself ;) .
You mean a launcher?
geir
>
>
> best,
> -Rob
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Davanum Srinivas <da...@gmail.com>.
Rob,
you mean JCVM?
-- dims
On 5/19/05, Rob Gonzalez <ro...@gmail.com> wrote:
> > > - jc (written in C)
> > > - jikes rvm (written in java)
> >
> > Between those two I'm on the side of jc becuase it should run faster
> > than jikes rvm, I don't know why it wouldn't. Though I don't know why
> > Kaffe isn't on the list.
>
> AFAICT JC is the only real option on the table right now.
>
> - jc was donated under the apache license.
>
> - JikesRVM is CPL, so i don't believe it's automatically on the table
> without IBM's releasing a version under the apache license.
>
> - Kaffe is GPL and no one organization or person owns the copyright
> (as compared to GNU projects, for example), so it's basically
> impossible to re-license.
>
>
> since we're now officially in the incubator, can we check this into an
> apache SVN repository and get hacking at it?
>
>
> Regarding the x-platform & modularity goals; regardless of whether
> most of the VM itself is written in Java, C, or whatever, having a
> small bootloading VM layer that instantiates the rest of the VM --
> again, a la JikesRVM -- is probably a good design decision and
> something that can be worked on immediately; not that I'm
> volunteering for that myself ;) .
>
>
> best,
> -Rob
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Developing Harmony
Posted by Rob Gonzalez <ro...@gmail.com>.
> > - jc (written in C)
> > - jikes rvm (written in java)
>
> Between those two I'm on the side of jc becuase it should run faster
> than jikes rvm, I don't know why it wouldn't. Though I don't know why
> Kaffe isn't on the list.
AFAICT JC is the only real option on the table right now.
- jc was donated under the apache license.
- JikesRVM is CPL, so i don't believe it's automatically on the table
without IBM's releasing a version under the apache license.
- Kaffe is GPL and no one organization or person owns the copyright
(as compared to GNU projects, for example), so it's basically
impossible to re-license.
since we're now officially in the incubator, can we check this into an
apache SVN repository and get hacking at it?
Regarding the x-platform & modularity goals; regardless of whether
most of the VM itself is written in Java, C, or whatever, having a
small bootloading VM layer that instantiates the rest of the VM --
again, a la JikesRVM -- is probably a good design decision and
something that can be worked on immediately; not that I'm
volunteering for that myself ;) .
best,
-Rob
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 17, 2005, at 11:09 PM, Bryce Leo wrote:
>> We are *NOT* going to be writing a JVM from scratch, we are open for
>> donations.
>>
>
> So why wasn't this cleared up from the start? Why state steadfastly
> that it was open and plausible. Ambiguity wastes time, obviously,
> maybe the Apache "moderators" (for lack of a better word) should go
> and list what is probably plausible and probably not plausible for the
> suggested implementation of the jvm, libraries etc.
I actually don't see why anything is off the table. If we decide to
write something from scratch, we do it.
I don't really want to (being lazy... :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Bryce Leo <li...@gmail.com>.
> We are *NOT* going to be writing a JVM from scratch, we are open for
> donations.
So why wasn't this cleared up from the start? Why state steadfastly
that it was open and plausible. Ambiguity wastes time, obviously,
maybe the Apache "moderators" (for lack of a better word) should go
and list what is probably plausible and probably not plausible for the
suggested implementation of the jvm, libraries etc.
>
> Currently we have two potential candidates:
>
> - jc (written in C)
> - jikes rvm (written in java)
Between those two I'm on the side of jc becuase it should run faster
than jikes rvm, I don't know why it wouldn't. Though I don't know why
Kaffe isn't on the list.
>
> if you own a JVM written in Pascal or C++ or Lisp or Smalltalk or OCML
> or Perl or Oberon or Prolog or ADA or Eiffel or RPG/3 or COBOL or
> whatever other programming language and you are willing to donate it and
> license it under the Apache License, make your voice heard on the
> language topic, if not, don't!
And this part is completely unnecessary, and bothersome. If you have
somethign to say, say it and don't bother with the flaming.
--
~Bryce Leo
--Veritas Vos Liberabis--
Re: Developing Harmony
Posted by Stefano Mazzocchi <st...@apache.org>.
Bryce Leo wrote:
> Now don't go too crazy for my suggesting this, but why not pascal? If
> we're considering C as it is this really isn't a terrible suggestion.
> I know it's fallen out of favor with most of you guys but it compiles
> quickly and supports a good number of operating systems and types of
> hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
> betting that you guys won't like it but I think the option should be
> listed.
>
> Opinions?
Can we stop this language madness thing, please?
We are *NOT* going to be writing a JVM from scratch, we are open for
donations.
Currently we have two potential candidates:
- jc (written in C)
- jikes rvm (written in java)
if you own a JVM written in Pascal or C++ or Lisp or Smalltalk or OCML
or Perl or Oberon or Prolog or ADA or Eiffel or RPG/3 or COBOL or
whatever other programming language and you are willing to donate it and
license it under the Apache License, make your voice heard on the
language topic, if not, don't!
--
Stefano.
Re: Developing Harmony
Posted by Stuart Still <st...@gmail.com>.
It is just not as popular as the others. If pascal was used, there
would be an awful lot of people unable to make contributions until
they learned pascal. I think the real question is what features
could pascal provide that would make it a better choice than the more
popular choice of C/C++.
Regards
Stuart
On 17 May 2005, at 18:54, Bryce Leo wrote:
> Now don't go too crazy for my suggesting this, but why not pascal? If
> we're considering C as it is this really isn't a terrible suggestion.
> I know it's fallen out of favor with most of you guys but it compiles
> quickly and supports a good number of operating systems and types of
> hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
> betting that you guys won't like it but I think the option should be
> listed.
>
> Opinions?
>
> ~Bryce Leo
>
>
> --Veritas Vos Liberabis--
>
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 17, 2005, at 1:54 PM, Bryce Leo wrote:
> Now don't go too crazy for my suggesting this, but why not pascal?
Wow. I've never had such a strong urge to vote someone "off the
island" :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Bryce Leo <li...@gmail.com>.
Now don't go too crazy for my suggesting this, but why not pascal? If
we're considering C as it is this really isn't a terrible suggestion.
I know it's fallen out of favor with most of you guys but it compiles
quickly and supports a good number of operating systems and types of
hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
betting that you guys won't like it but I think the option should be
listed.
Opinions?
~Bryce Leo
--Veritas Vos Liberabis--
Re: Developing Harmony
Posted by Ozgur Akan <ak...@aiqa.com>.
Hi,
I also prefer C which is simpler to use and also As Nicolas said has
smaller memory footprint.
Ozgur Akan
Simon Chappell wrote:
>On 5/16/05, Ben Laurie <be...@algroup.co.uk> wrote:
>*snip*
>
>
>>Question to the floor: if it had to be one of C and C++, which would you
>>prefer?
>>
>>
>
>C.
>
>C++ was a terrible thing to do to a language! :-)
>
>Simon
>
>
>
Re: Developing Harmony
Posted by Stefano Mazzocchi <st...@apache.org>.
Simon Chappell wrote:
> On 5/16/05, Ben Laurie <be...@algroup.co.uk> wrote:
> *snip*
>
>>Question to the floor: if it had to be one of C and C++, which would you
>>prefer?
Thanks Ben, that is a very productive question.
--
Stefano.
Re: Developing Harmony
Posted by Simon Chappell <si...@gmail.com>.
On 5/16/05, Ben Laurie <be...@algroup.co.uk> wrote:
*snip*
> Question to the floor: if it had to be one of C and C++, which would you
> prefer?
C.
C++ was a terrible thing to do to a language! :-)
Simon
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Geir Magnusson Jr. wrote:
>
> On May 16, 2005, at 11:51 AM, Ben Laurie wrote:
>
>>
>> I'm pretty sure we want a framework in C/C++, whatever components are
>> developed in.
>
>
> +1
>
>>
>> Question to the floor: if it had to be one of C and C++, which would
>> you prefer?
>
>
> C++
>
> Oog. <grunt> Thog like to bang rocks, but Thog also like inheritance,
> ABCs and generics.
Plus it looks like we're going to get STL at the ASF soon, too :-)
If we do use C++, then we need to be pretty strict about the subset. So
long as we have a good variety of platforms amongst developers I imagine
that'll Just Happen(tm).
What, btw, are ABCs?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 17, 2005, at 2:14 PM, Mark Brooks wrote:
>> Oog. <grunt> Thog like to bang rocks, but Thog also like
>> inheritance, ABCs and generics.
>>
>
> If by "generics" you mean STL, it is my understanding that creates
> cross-platform problems, which is why many cross-platform C++
> projects don't use it.
Thog still like :)
But yes, I'm perfectly ready to accept self-imposed limitations.
It's been a while since I did C++ in anger, so happy to listen to
whomever is doing it currently for real things.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Mark Brooks <jm...@hotmail.com>.
>Oog. <grunt> Thog like to bang rocks, but Thog also like inheritance, ABCs
>and generics.
If by "generics" you mean STL, it is my understanding that creates
cross-platform problems, which is why many cross-platform C++ projects don't
use it.
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: Developing Harmony
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 16, 2005, at 11:51 AM, Ben Laurie wrote:
>
> I'm pretty sure we want a framework in C/C++, whatever components
> are developed in.
+1
>
> Question to the floor: if it had to be one of C and C++, which
> would you prefer?
C++
Oog. <grunt> Thog like to bang rocks, but Thog also like inheritance,
ABCs and generics.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Brett Porter wrote:
>>LLVM looks cool, but comes with a wholebunchastuff under different
>>licenses embedded in it. A casual inspection suggests we can probably
>>work around them, but a closer inspection would be required.
>
>
> They all looked to be the same with additional copyrights, ie BSD-ish,
> with the exception of a stripped down libc which is LGPL. But I'll
> respect Leo's rights to not discuss licensing issues :) This means it
> should probably be evaluated on its merits.
Don't go too far with that - any code we commit has to have a licence we
can live with. That means anything in the (current) core, of course.
So, we can not worry about classpath, but I don't think we can not worry
about the JVM.
>>I don't really buy this is a drawback, since whatever you choose,
>>everybody'll have to learn it.
>>
>>It would be wrong to assume that everyone involved in this project is
>>totally in love with Java :-)
>
> I'd have thought everyone knew it though, or at least wanted to learn
> it, given they are implementing, well, Java :)
Sure enough. Still doesn't mean they want to implement a JVM in it :-)
>>I'm pretty sure we want a framework in C/C++, whatever components are
>>developed in.
>>
>>Question to the floor: if it had to be one of C and C++, which would
>>you prefer?
>
> If it came down to that, I think C++ for 3 reasons:
> - the concepts are a lot closer to Java, which should make most people
> feel more comfortable, and should there be any wanting to later write a
> component in Java instead or vice-versa, the design structure is less
> likely to change
> - it would give an opportunity to work with a new incubator project
> (should it be accepted)
?
> - you can still use any C APIs in C++, but the reverse is not true (or
> at least, not easy).
Actually, it really isn't that hard...
x.f(a,b,c);
just becomes
f_variant1(x,a,b,c);
not that this generally leads to anything you'd want to use :-)
Certainly the other way around is less crufty.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Brett Porter <br...@apache.org>.
>
> LLVM looks cool, but comes with a wholebunchastuff under different
> licenses embedded in it. A casual inspection suggests we can probably
> work around them, but a closer inspection would be required.
They all looked to be the same with additional copyrights, ie BSD-ish,
with the exception of a stripped down libc which is LGPL. But I'll
respect Leo's rights to not discuss licensing issues :) This means it
should probably be evaluated on its merits.
>
> I don't really buy this is a drawback, since whatever you choose,
> everybody'll have to learn it.
>
> It would be wrong to assume that everyone involved in this project is
> totally in love with Java :-)
I'd have thought everyone knew it though, or at least wanted to learn
it, given they are implementing, well, Java :)
>
> I'm pretty sure we want a framework in C/C++, whatever components are
> developed in.
>
> Question to the floor: if it had to be one of C and C++, which would
> you prefer?
If it came down to that, I think C++ for 3 reasons:
- the concepts are a lot closer to Java, which should make most people
feel more comfortable, and should there be any wanting to later write a
component in Java instead or vice-versa, the design structure is less
likely to change
- it would give an opportunity to work with a new incubator project
(should it be accepted)
- you can still use any C APIs in C++, but the reverse is not true (or
at least, not easy).
Cheers,
Brett
Re: Developing Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Tom Tromey wrote:
>>>>>>"Steve" == Steve Blackburn <St...@anu.edu.au> writes:
>
>
> Steve> I am going to stick my neck out and make a few concrete suggestions
> Steve> for how the Harmony VM might be developed.
>
> Excellent post.
>
>
> I would like to mention a different possibility:
>
> * Write a new, modular VM in C or C++
> - Go through the interoperability list[1] and define internal
> modules along these boundaries
> - Pick 2-3 use cases as target environments. I suggest "small
> embedded", "desktop application", and "j2ee server"
> - Make good reference choices
> * Use Classpath as the class library
> * Port MMTk to C, or otherwise find a way to use it
Or use it to test the "modular, in any language" concept.
> * Use LLVM[2] as the JIT engine
LLVM looks cool, but comes with a wholebunchastuff under different
licenses embedded in it. A casual inspection suggests we can probably
work around them, but a closer inspection would be required.
> * Write an interpreter engine as well, for special situations (small
> memory). Assuming Classpath proves to have an acceptable license,
> which really IMNSHO is the only sane possibility, we can just copy
> over the one from libgcj.
>
>
> Drawbacks of this plan:
>
> * JikesRVM is further along, so longer time to "hello world"
> * Everybody has to learn C++ (or C)
I don't really buy this is a drawback, since whatever you choose,
everybody'll have to learn it.
It would be wrong to assume that everyone involved in this project is
totally in love with Java :-)
I'm pretty sure we want a framework in C/C++, whatever components are
developed in.
Question to the floor: if it had to be one of C and C++, which would you
prefer?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Developing Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Steve" == Steve Blackburn <St...@anu.edu.au> writes:
Steve> I am going to stick my neck out and make a few concrete suggestions
Steve> for how the Harmony VM might be developed.
Excellent post.
I would like to mention a different possibility:
* Write a new, modular VM in C or C++
- Go through the interoperability list[1] and define internal
modules along these boundaries
- Pick 2-3 use cases as target environments. I suggest "small
embedded", "desktop application", and "j2ee server"
- Make good reference choices
* Use Classpath as the class library
* Port MMTk to C, or otherwise find a way to use it
* Use LLVM[2] as the JIT engine
* Write an interpreter engine as well, for special situations (small
memory). Assuming Classpath proves to have an acceptable license,
which really IMNSHO is the only sane possibility, we can just copy
over the one from libgcj.
Drawbacks of this plan:
* JikesRVM is further along, so longer time to "hello world"
* Everybody has to learn C++ (or C)
Benefits of this plan:
* LLVM holds the promise of being able to combine JIT and AOT
compilation
* Configurable VM means it is simpler to target the small machine
embedded scenario
* Re-use somebody else's compiler framework. For AOT, re-use lessons
learned by gcj.
Tom
[1] http://lists.gnu.org/archive/html/classpath/2004-01/msg00033.html
[2] http://www.llvm.org/
Re: Developing Harmony
Posted by Davanum Srinivas <da...@gmail.com>.
Added your thoughts to wiki - http://wiki.apache.org/harmony
thanks,
dims
On 5/13/05, Steve Blackburn <St...@anu.edu.au> wrote:
> I am going to stick my neck out and make a few concrete suggestions
> for how the Harmony VM might be developed.
>
> A few motivating goals:
>
> o Focus on modular, interchangeable components
> - exploit existing compilers, memory managers etc
> - promote configurability (different components for different contexts)
> - allow diversity in development approaches
> - encourage large-scale contributions (here's a compiler)
>
> o Bootstrap the project rapidly
> - capture momentum
> - seed the project with an existing VM-core (or cores)
>
> o Design a clean core (or cores) from scratch
> - do this concurrently with work on components in existing core/s
> - the core should be lightweight
> - multiple cores may make sense
> - the needs of different contexts may require this
> - competing approaches may be healthy
>
> A concrete option:
>
> 1. Use two VMs as seeds
> a) Jikes RVM is a possible candidate
> . Focus energy on cleaning it up and modularizing it. This is
> something we've already begun (see earlier post), but will
> take a lot of work.
> + Get a very good optimizing compiler
> + Get an efficient and modular memory management toolkit
> (MMTk)
> - Need to deal with licensing issues and gain the consent of
> the community (not insurmountable)
> - Need hard work to achieve modularity goal for whole VM
>
> b) Another very different VM (kaffe?)
> . amenable to modularization
> . amenable to other components (drop in MMTk?)
>
> 2. Leverage extensive experience to build new core/s
> . Start with a clean slate
> . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> jnode,...)
> . Work concurrently with above work on components in old core/s,
> miminize loss of momentum, try to really think it through
> carefully.
> . May be sensible to develop more than one core
>
> 3. Develop new components
> . Extract components from existing work, apply to new VM/s
> . Develop new components from scratch
> . Encourage porting of existing compilers etc into this framework
>
>
> Alternative options:
>
> o Start with just one seed
>
> o There are many different ways... the above is indicative, not exclusive
>
>
> OK. So I've stuck my neck out. The above is vague and very
> ambitious, but those rough thoughts come out of a lot of experience
> with VM design---not just mine but the experience of those who I've
> been discussing this with and working with. A component based VM is
> not trivial at all. I've not mentioned any of the vast complexity
> that lies within a real VM. However, my experience with porting MMTk
> across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> working on porting to jnode--Java) gives me hope!
>
> Cheers,
>
> --Steve
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/