You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Rodrigo Kumpera <ku...@gmail.com> on 2005/05/16 21:58:16 UTC
Stop this framework/modularity madness!
Making Harmony modular enouth to be kind of a JVM framework cannot be
done before having a working JVM. There is a lot of literature about
how frameworks should emerge from continuous design and development.
This must not be the focus until required, so no JIT plugable layer
until someone tries to write another JIT for Harmony (emphasis on
another).
Creating such is a big chalenge, to guess what spots need to flexible
and the others that don't. Guess what, people often make bad guesses
about these and in the end we have a very complex design with a lot of
shortcomings.
I believe the focus should be on deciding if Harmony will star from
other JVM or not.
Rodrigo
Re: Stop this framework/modularity madness!
Posted by Stefano Mazzocchi <st...@apache.org>.
Royce Ausburn wrote:
> In my experience, delaying the 'modular design' of a system causes more
> work.
More coding work? sure thing.
If you factor into "work" the amount of email and time and emotional
energy you will have to consume to get to that modular design over a
mail list with 100 people, all thinking they know it best, the ratio
might change.
Food for thought.
--
Stefano.
Re: Stop this framework/modularity madness!
Posted by Rodrigo Kumpera <ku...@gmail.com>.
Maybe this pluggable layer that is not well defined. I think that having
this as a link time thing is more than enouth. It doesn´t mean that only one
GC algorithm or JITer will be available at runtime, but all the options
should be defined when building the JVM.
Refactoring a system to have a framework emerge is a lot easier, productive
and produce less cluter. Lets not make generic what doesn't need to be.
But a better argument is close inspection of this list archive. Seens like
nobody trully knows how to proper layer a JVM for good modularity. The
JikesRVM folks are refactoring to make this possible on their JVM, but right
now they can't really say how it will look when finished.
Rodrigo
On 5/17/05, Royce Ausburn <es...@gmail.com> wrote:
>
>
> Ack - Sorry about the incomplete mail.
>
> On 17/05/2005, at 3:58 AM, Rodrigo Kumpera wrote:
>
> >
> > This must not be the focus until required, so no JIT plugable layer
> > until someone tries to write another JIT for Harmony (emphasis on
> > another).
> >
>
> In my experience, delaying the 'modular design' of a system causes
> more work. When you rip out the old part, not only do you have to
> design and implement this pluggable layer, this layer probably needs
> alot more design work because you have to consider all the other
> systems that are affected. This also isn't easy because the project
> hasn't been designed in a modular fashion. THen you have to
> reimplement the old part (the JIT bit in your example) - May as well
> design everything to work together in harmony to begin with.
>
> --Royce
>
>
Re: Stop this framework/modularity madness!
Posted by Royce Ausburn <es...@gmail.com>.
Ack - Sorry about the incomplete mail.
On 17/05/2005, at 3:58 AM, Rodrigo Kumpera wrote:
>
> This must not be the focus until required, so no JIT plugable layer
> until someone tries to write another JIT for Harmony (emphasis on
> another).
>
In my experience, delaying the 'modular design' of a system causes
more work. When you rip out the old part, not only do you have to
design and implement this pluggable layer, this layer probably needs
alot more design work because you have to consider all the other
systems that are affected. This also isn't easy because the project
hasn't been designed in a modular fashion. THen you have to
reimplement the old part (the JIT bit in your example) - May as well
design everything to work together in harmony to begin with.
--Royce
Re: Stop this framework/modularity madness!
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodrigo Kumpera wrote:
> Making Harmony modular enouth to be kind of a JVM framework cannot be
> done before having a working JVM. There is a lot of literature about
> how frameworks should emerge from continuous design and development.
There's a lot of literature about all aspects of development that has
been gleefully ignored at the ASF :-)
> This must not be the focus until required, so no JIT plugable layer
> until someone tries to write another JIT for Harmony (emphasis on
> another).
>
> Creating such is a big chalenge, to guess what spots need to flexible
> and the others that don't. Guess what, people often make bad guesses
> about these and in the end we have a very complex design with a lot of
> shortcomings.
There's a difference between having a framework and making the detailed
decisions about where flexibility is required.
IMO, a good framework lets you change your mind about where the hooks
are with ease. The system we use for hooks in httpd 2.0 is an example
(ok, I'm biased, I wrote it).
http://httpd.apache.org/docs-2.0/developer/hooks.html
explains hooks, but there's also another related facility - optional
functions - these are functions provided by modules that may or may not
be present. They're rather like hooks, except there's only one of them
(if you see what I mean). There is doxygen documentation but it seems
not to be online :-(
BTW, what that documentation doesn't make clear is that hook code is
type-safe throughout (except in the core implementation of the hook
handling code itself, of course).
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: Stop this framework/modularity madness!
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 16, 2005, at 3:58 PM, Rodrigo Kumpera wrote:
> Making Harmony modular enouth to be kind of a JVM framework cannot be
> done before having a working JVM. There is a lot of literature about
> how frameworks should emerge from continuous design and development.
There's been a lot of work in this area, and many of the people that
did it are here and willing to help...
Given that body of knowledge, why not?
>
> This must not be the focus until required, so no JIT plugable layer
> until someone tries to write another JIT for Harmony (emphasis on
> another).
>
> Creating such is a big chalenge, to guess what spots need to flexible
> and the others that don't. Guess what, people often make bad guesses
> about these and in the end we have a very complex design with a lot of
> shortcomings.
>
> I believe the focus should be on deciding if Harmony will star from
> other JVM or not.
>
We hope so :) We're lazy
geir
>
> Rodrigo
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Stop this framework/modularity madness!
Posted by Frederick C Druseikis <fd...@sc.rr.com>.
On Mon, 16 May 2005 16:58:16 -0300
Rodrigo Kumpera <ku...@gmail.com> wrote:
> Making Harmony modular enouth to be kind of a JVM framework cannot be
> done before having a working JVM. There is a lot of literature about
> how frameworks should emerge from continuous design and development.
THere are also several JVMs and JIT projects that can provide this current experience.
e.g. Sablevm, jamvm, Jikes RVM, CACAO, gcj/gij -- the list is rich enough
I have used all but Jikes RVM in the last two weeks against classpath
And there is also the experiences of LLVM, and IKVM even
So, I've got about 5 different builds of classpath on my machine; talk about confusing ! (to me...)
>
> This must not be the focus until required, so no JIT plugable layer
> until someone tries to write another JIT for Harmony (emphasis on
> another).
The point, IMHO, is to engage those projects in a constructive way.
Making a framework is constructive.
>
> Creating such is a big chalenge, to guess what spots need to flexible
> and the others that don't. Guess what, people often make bad guesses
> about these and in the end we have a very complex design with a lot of
> shortcomings.
Like J2EE? :)
This might be a design principle: Harmony shall not be like J2EE
>
> I believe the focus should be on deciding if Harmony will star from
> other JVM or not.
I think your suggestion could have the effect of putting the Harmony project into a "JVM Beauty Pageant" business.
Then there are winners and losers. Yech.,
Making a framework, even though it might be transiently imperfect, finesses the point; and besides, maybe a framework will allow a JVM that
might be judged "less beautiful" (ugly?) today to become much more beautiful tomorrow.
-Fred
Re: Stop this framework/modularity madness!
Posted by Stefano Mazzocchi <st...@apache.org>.
Rodrigo Kumpera wrote:
> Making Harmony modular enouth to be kind of a JVM framework cannot be
> done before having a working JVM. There is a lot of literature about
> how frameworks should emerge from continuous design and development.
I agree with Rodrigo.
> This must not be the focus until required, so no JIT plugable layer
> until someone tries to write another JIT for Harmony (emphasis on
> another).
Yep.
> Creating such is a big chalenge, to guess what spots need to flexible
> and the others that don't. Guess what, people often make bad guesses
> about these and in the end we have a very complex design with a lot of
> shortcomings.
>
> I believe the focus should be on deciding if Harmony will star from
> other JVM or not.
Agreed.
--
Stefano.
Re: Stop this framework/modularity madness!
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Rodrigo" == Rodrigo Kumpera <ku...@gmail.com> writes:
Rodrigo> Making Harmony modular enouth to be kind of a JVM framework
Rodrigo> cannot be done before having a working JVM.
Rodrigo> Creating such is a big chalenge, to guess what spots need to flexible
Rodrigo> and the others that don't. Guess what, people often make bad guesses
Rodrigo> about these and in the end we have a very complex design with a lot of
Rodrigo> shortcomings.
This list has plenty of people who have *already* implemented or
worked on JVMs. I think there is probably enough knowledge here to
succeed at this part of the effort.
Rodrigo> I believe the focus should be on deciding if Harmony will star from
Rodrigo> other JVM or not.
And in addition, deciding what the goals are. You wouldn't want to
pick a starting point that doesn't take you where you want to go.
Tom
Re: Stop this framework/modularity madness!
Posted by Peter Donald <pe...@realityforge.org>.
Steve Blackburn wrote:
> However, it is not the either/or situtation you paint above. I think
> it may make most sense to work on a preexisting donated VM or VMs
> while *concurrently* developing a new VM core or cores from scratch.
> This approach has a number of advantages, including maximizing our
> leverage from existing work, minimizing startup time and accelerating
> the process of building an existing VM. It also allows us to more
> fruitfully explore some of the implementation choices (which language
> to use, ...).
FWIW there is precedent for that process happening at Apache. Tomcat3
was largely donated by Sun and people hacked on that for a while until
they understood how a newer shinier servlet container could be built.
There was a bit more ruckus involved in this process than was strictly
required but the community seems to have got back on track with tomcat5.
Hopefully some of the old hat Apache peeps can help minimize the heat
during harmonys evolution but this is definetly a good way to proceed IMHO.
> The donated VM or VMs (if they araise) may already be at this point.
> As I have already said, this is a process already underway in the
> Jikes RVM project.
excellent.
--
Cheers,
Peter Donald
"Nothing changes your opinion of a friend so surely
as success - yours or his." - Franklin P. Jones
Re: Stop this framework/modularity madness!
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Rodrigo,
>I believe the focus should be on deciding if Harmony will star from
>other JVM or not.
>
I agree entirely that this is an important issue, and a lot of people
are working hard right now to see if this can happen. Donating an
entire JVM to apache is not a trivial issue, so we will need to be patient.
However, it is not the either/or situtation you paint above. I think it
may make most sense to work on a preexisting donated VM or VMs while
*concurrently* developing a new VM core or cores from scratch. This
approach has a number of advantages, including maximizing our leverage
from existing work, minimizing startup time and accelerating the process
of building an existing VM. It also allows us to more fruitfully
explore some of the implementation choices (which language to use, ...).
[previously you wrote...]
>Making Harmony modular enouth to be kind of a JVM framework cannot be
>done before having a working JVM. There is a lot of literature about
>how frameworks should emerge from continuous design and development.
>
>
The donated VM or VMs (if they araise) may already be at this point. As
I have already said, this is a process already underway in the Jikes RVM
project. I can't speak for the other projects, but they may also be at
such a stage or, better, have moved beyond that stage.
>This must not be the focus until required, so no JIT plugable layer
>until someone tries to write another JIT for Harmony (emphasis on
>another).
>
>
I would like to leverage prexisting VMs to push the process of
modularization.
>Creating such is a big chalenge, to guess what spots need to flexible
>and the others that don't. Guess what, people often make bad guesses
>about these and in the end we have a very complex design with a lot of
>shortcomings.
>
>
Right. This is why it is essential that harmony learn from kaffe, gcj,
jikesrvm, sable, ovm, joeq, etc etc. The project does not exist in a vacum.
--Steve