Re: mudGE VM (was RE: Developing Harmony)

[Tom van Dijck]

It does not
however, since it is about 100 times less work to maintain vcproj and sln
files opposed to makefiles (at least in my oppinion) it just comes with
build files for the commercially most used compiler in the world.
Anyway, anyone with knowledge about ant or makefiles could get the thing
compiling using gcc, or any other compiler.
Next to that... the mudCore library is some sort of a hardware abstraction
layer for the rest of the engine, if you make a linux version of that, like
I did for PS2, Xbox and MAC, then compiling the rest of the modules for any
other platform would not be a problem at all...

Tommie.

- Original Message - 
From: "Steven Gong" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, May 21, 2005 11:56 AM
Subject: Re: mudGE VM (was RE: Developing Harmony)


On 5/20/05, Nick Lothian <[EMAIL PROTECTED]> wrote:
>
> Try "mudGE VM".
>
> The link is www.mudge.nl/java/ 
>
Oh, it needs m$ vs.net  :(
-- 
Best Regards
Steven Gong

Threading

[Craig Blake]

Just out of curiosity, can anyone familiar with the various OSS VM  
implementations being discussed share their insights regarding the  
respective threading capabilities?  I have heard of some commercial  
specialty VMs handling upwards of 30,000 concurrent threads easily  
and it would be wonderful to be able to have that sort of scalability  
(or more!) available in the Harmony effort.


Thanks,
Craig

Re: Harmony and JamVM (Re: JIRA and SVN)

[Peter Donald]

Hi,

For those of you who have not played with a JVM before and want to get a 
feel for how to implement them I would highly suggest you have a look at 
the JamVM codebase.This is a really nice codebase to read and it is 
relatively simple to understand - at least as far as JVMs go. Congrats 
Robert!



---
Cheers,

Peter Donald

 These aren't the droids you're
 looking for. Move along.

Relicensing and/or donating code (was: JIRA and SVN)

[Leo Simons]

On 22-05-2005 00:49, "Robert Lougher" <[EMAIL PROTECTED]> wrote:
> The major problem with JamVM as regards Harmony is that it is
> currently licensed under the GPL.  I originally had some specific
> reasons for doing this, however, I am open to suggestions about
> different licensing models, e.g. dual-licensing, adoption of LGPL or a
> linking exception as in GNU Classpath.  Assuming the license issue
> could be sorted out,

By far the easiest and safest option for you if you would like Harmony and
JamVM to be "legally compatible" is probably to dual-license under both the
GPL and one of

 -> Apache License 2.0
 -> MIT/X11 License (basically revised BSD license)
 -> Mozilla Public License, CPL, or similar

If that is acceptable to you from a moral/philosophical/... point of view.

As for choosing "which one", IMHO (IANAL!) the main advantage of MIT is that
its real simple and short, the main advantage of AL over MIT is a little bit
of patent protection. The other big advantage of MIT license is that the FSF
feels it is compatible with the GPL whereas the same cannot be said for the
ASL, but if you're dual-licensing under the GPL as well that becomes a moot
point.

Then again, I don't reallly know why one would actually license under both
MIT license and GPL license: anyone could take your code, change 5 lines,
put those under the GPL, and the entire combined work would be under the
GPL, so you might as well just license under MIT license only. I think.

Then again, I have no idea why people whould choose MPL or CPL, but they do
that as well; IANAL.

> and if (and it's a big if) JamVM was adopted as
> one of the seed VMs my next concern would be what happens next. Would
> it be a fork?  Would I continue to work on JamVM as now?  Of course,
> change is not necessarily a bad thing.

Well, another alternative you can consider is donating JamVM to the ASF.
That would mean a code grant
(http://www.apache.org/licenses/software-grant.txt). It would mean that
JamVM would become an integral part of harmony, you become one of Harmony's
committers (at least I'd hope so! But the two aren't necessarily coupled),
and the entire work is from that point on licensed under the AL, brought
into the ASF version control repositories, etc etc. Of course, bringing a
big piece of code into a project requires the project's PPMC to decide it
wants that to happen, its not something the donating party decides on its
own :-)

I'd say that's a lot bigger a change than merely changing the license or
starting to dual-license. Depends on what y'all want to do :-D

Of course it would then still be possible to keep developing JamVM on its
own as well under a license of your choice (ie the ASF version would then
become a fork of some sort) but I'd advise against that kind of deal since
it leads to duplication of effort.

Gnight!

Leo

Re: Harmony and JamVM (Re: JIRA and SVN)

[Steve Blackburn]

JamVM sounds very interesting.  A fast lightweight interpreter has at 
least two attractions:


a) portability (this is true regardless of the implementation language, 
the point is that an interpreter does not require a new compiler backend 
to be written for each architecture)

b) compactness

If the lightweight interpreter were a pluggable component, or if we 
could use JamVM as a prototype for a pluggable lightweight interpreter, 
I think that would be a real asset.


Rob, what do you think?  Could the JamVM interpreter be extracted as a 
pluggable module?  Could the JamVM interpreter be used as a protype for 
a new componentized implementation (will your insights and lessons 
translate well into a new implementation, or are they mostly 
JamVM-specific?)


Is the GC exact or conservative?

In other words, how can Harmony make the most of JamVM's most valuable 
ideas?


Cheers,

--Steve

Harmony and JamVM (Re: JIRA and SVN)

[Robert Lougher]

I meant to change the subject line.  Oh well.  You'll find the rest of
my response under Re: JIRA and SVN.

Rob.

On 5/21/05, Robert Lougher <[EMAIL PROTECTED]> wrote:
> Hi List,
> 
> Now that I've been explicitly asked, I'll forego my current observer
> status and give some  input :)  First off, I'm not comfortable pushing
> JamVM, but I'll give a summary for people who are unfamiliar with it.
> 
...

Re: JIRA and SVN

[Robert Lougher]

Hi List,

Now that I've been explicitly asked, I'll forego my current observer
status and give some  input :)  First off, I'm not comfortable pushing
JamVM, but I'll give a summary for people who are unfamiliar with it.

As has already been alluded to, JamVM's main claim is its small size
(currently, its stripped executable weighs in at ~135K on PowerPC and
100K on Intel).  This makes it suitable for use on platforms ranging
from embedded ARM processors, up to desktop machines and SMP systems
(it has appropriate memory barriers for PowerPC and Intel), and it
could also be used as a bootstrap VM.  Its small size is a result of
conscious design decisions and effort.  It may not be the most
sophisticated VM out there, but it has proved to be complete, stable
and fast enough for many of the GNU Classpath developers to adopt it
as their development VM.  The interpreter in particular, is
"state-of-the-art", supporting direct-threading, stack-caching,
prefetching and common super-instructions.  See
http://www.csc.uvic.ca/~csc586a/slides/StackCaching-4.pdf and
http://www.csc.uvic.ca/~csc586a/Ass1.pdf for an advanced academic
course on virtual machines using JamVM.

JamVM has currently been built and tested on Linux for the ARM,
PowerPC and IA32 architectures, and on Mac OS X/Darwin for PowerPC. 
Porting to a new architecture/platform involves writing a couple of
assembler macros for atomic operations (used in the thin-locking
implementation) and for memory barriers.  A separate function must
also be implemented which handles the construction of a native C call
stack frame and perform parameter passing for invoking native JNI
methods.  This could, however, be simplified in the future by
providing the option to use libffi instead.  JamVM also includes the
option to use an internal native interface which is much more
efficient than JNI.

The current latest version of JamVM is 1.3.0 (see
http://jamvm.sf.net).  This works "out-of-the-box" with GNU
Classpath-0.15 (the latest snapshot) and CVS head.  I'm currently
finishing off JamVM 1.3.1, this is a maintenance release which
includes a couple of minor bug-fixes and some performance
optimisations for object and array allocation.  It will also include
the patches enabling JamVM to boot the GNU Classpath generics branch
(the branch for Java 1.5 features).  See
http://lists.gnu.org/archive/html/classpath/2005-04/msg5.html.

The major problem with JamVM as regards Harmony is that it is
currently licensed under the GPL.  I originally had some specific
reasons for doing this, however, I am open to suggestions about
different licensing models, e.g. dual-licensing, adoption of LGPL or a
linking exception as in GNU Classpath.  Assuming the license issue
could be sorted out, and if (and it's a big if) JamVM was adopted as
one of the seed VMs my next concern would be what happens next. Would
it be a fork?  Would I continue to work on JamVM as now?  Of course,
change is not necessarily a bad thing.

Hope this helps,

Rob.

On 5/21/05, Raffaele Castagno <[EMAIL PROTECTED]> wrote:
> 2005/5/21, Davanum Srinivas <[EMAIL PROTECTED]>:
> >
> > David,
> >
> > please feel free to ping Rob. It would be great!
> >
> > thanks,
> > dims
> >
> > On 5/21/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> > > On 20 May 2005 17:54:11 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > This is too vague -- we don't know much about the unexpected. Plus,
> > > > in most cases, the "core" part of the VM is simply not very important.
> > > > There just isn't much code there -- JamVM is 20KLOC, anybody could
> > > > comfortably rewrite this.
> > >
> > >
> > > Hmmm, well I used to work with the author of JamVM (Rob Lougher) and
> > he's
> > > one of the brightest guys I know. I think you'll find that the low LOC
> > > figure is testament to his ability to write lean code rather than an
> > > indication of how easy it is to knock off a JVM on a wet Sunday
> > afternoon.
> > >
> > > BTW has anyone asked Rob about donating JamVM to Harmony? As the
> > (currently)
> > > sole owner he should have no problem with switching licenses.
> > >
> > > Cheers,
> > >
> > > Dave
> > >
> > >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 
> 
> 
> --
> If you want a GMail account, send me an E-Mail.
> 
>

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)

[Geir Magnusson Jr.]

On May 21, 2005, at 4:14 PM, Stefano Mazzocchi wrote:


Geir Magnusson Jr. wrote:



On May 21, 2005, at 9:51 AM, Stefano Mazzocchi wrote:




If the mentors of this project were to write a JVM themselves,  
it  would

be a piece of crap :-)



Don't sell everyone so short...  :)



Prove me wrong! :-)


I have no doubts :)

geir

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)

[Stefano Mazzocchi]

Geir Magnusson Jr. wrote:
> 
> On May 21, 2005, at 9:51 AM, Stefano Mazzocchi wrote:
> 
>>
>> If the mentors of this project were to write a JVM themselves, it  would
>> be a piece of crap :-)
> 
> Don't sell everyone so short...  :)

Prove me wrong! :-)

-- 
Stefano.

Re: [DOCUMENTATION][WIKI] Proposal and Initial FAQ in Italian.

[Geir Magnusson Jr.]

Thank you!

On May 20, 2005, at 3:48 AM, Raffaele Castagno wrote:


I've translated the initial proposal and the FAQ in Italian.

http://wiki.apache.org/harmony/Apache_Harmony_Proposal_Italian
http://wiki.apache.org/harmony/Initial_FAQ_Italian

Best regards.

Raffaele

--
If you want a GMail account, send me an E-Mail.



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Developing Harmony

[Geir Magnusson Jr.]

On May 20, 2005, at 2:55 AM, Rafal Lewczuk wrote:


Hi,

On 5/19/05, Ian Darwin <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)

[Geir Magnusson Jr.]

On May 21, 2005, at 9:51 AM, Stefano Mazzocchi wrote:


If the mentors of this project were to write a JVM themselves, it  
would

be a piece of crap :-)


Don't sell everyone so short...  :)

geir

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Geir Magnusson Jr.]

On May 21, 2005, at 12:08 AM, Steve Blackburn wrote:


Mark Brooks wrote:


Investigation is fine enough, but let's face facts.  This is a  
HUGE project.


We do NOT have the time or manpower to write two VMs as part of a  
project where we need a working J2SE 5 implementation, from  
basement to TV aerial so to speak, and we need it in time to be  
relevant.  Even with donated code, it won't work to do VMs in  
parallel.




I think it would be insane to develop multiple VMs in parallel.
Fortunately, I don't think anyone is proposing that.


I hope not.

I'd really like to see

0) Lets remember the timescale here - this is going to be years,  
probably.


1) A little more discussion around the parts that go into a VM, no  
matter what language we're working in.


2) People playing with the existing VMs we're talking about using.   
These right now are all open-source VMs - you can get them now and  
play with them.  We call can.  We don't need to move them here.  We  
might choose to do it later, or we might choose to start over if our  
analysis of what came before leads us to that conclusion.




The seeding model I have pushed would only have multiple VMs on the  
table during the seeding process.  That is something I envisage  
would take three to nine months.  During that time the community  
will have the opportunity to engage with the projects and gain much  
needed experience and insight into how a real VM is built.   
Concurrently new cores would be architected and built. The VM cores  
are small but they are the centerpiece and getting them right is  
critical.  Therefore, as far as the cores go, I am much less  
concerned about person power than I am about informed design  
decisions.  The bulk of the work is going to be in achieving  
completeness, improving packaging, fixing known shortcomings,  
smoothing corners etc etc.


Yes - and we can start *right now* without having them here.



With a strong component based model, different configurations could  
be built for different purposes.  This is not a radical idea nor is  
it rocket science---we already do it in Jikes RVM (you choose your  
compiler and your GC ahead of time and tailor the VM accordingly).   
I am sure other VMs do this as well.  If we're going to try to  
cover the desktop, servers and embedded devices, then reuse is  
going to be key.


Yes, and this is one of the original premises of the project.  It  
would be nice to start that component model discussion :)


geir



--Steve




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Mark Brooks]

> We do NOT have the time or manpower to write two VMs as part of a
> project where we need a working J2SE 5 implementation, from basement to
> TV aerial so to speak, and we need it in time to be relevant.  Even with
> donated code, it won't work to do VMs in parallel.

Look around: do you really think manpower is your scarcity point?


As a matter of fact, I do.

We are not a group of experts operating under a clear plan.  We are a 
disparate group of people with a common interest and different ability 
levels in different things.


This is something we can do, but I think you are underestimating the 
complexity of the project.  This is something that will take a couple of 
years to get to the point where we have something useful.  Unless of course 
we just glue together somebody else's components, in which case, maybe not, 
but then, you are stuck with your code base, unless you try to rewrite it, 
in which case, you are taking as much time as writing it from scratch.


Go take a look at the J2SE 5 documentation and see all the components that 
will need to be developed, all the library code that will need to be 
implemented.  The JRE isn't massive because the code is all fluff.


Many hands can make light work, but work it will be, and only a sustained 
and focused effort will succeed.


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: how long till start?

[Raffaele Castagno]

Project has been approved already, and is officially started:

http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740
http://svn.apache.org/repos/asf/incubator/harmony/

Anyway, it's still in the "planning&designing" phase.

Feel free to partecipate...

Raffaele (as a simple observer...)

2005/5/21, crispyalien <[EMAIL PROTECTED]>:
> 
> Hi, Does anybody know when will this project start officialy? Does it
> need to be aproved? whe will happend that?
> 
> regards,
> Valentin
> 



-- 
If you want a GMail account, send me an E-Mail.

how long till start?

[crispyalien]

Hi, Does anybody know when will this project start officialy? Does it 
need to be aproved? whe will happend that?


regards,
Valentin

Re: JIRA and SVN

[Raffaele Castagno]

2005/5/21, Davanum Srinivas <[EMAIL PROTECTED]>:
> 
> David,
> 
> please feel free to ping Rob. It would be great!
> 
> thanks,
> dims
> 
> On 5/21/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> > On 20 May 2005 17:54:11 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > This is too vague -- we don't know much about the unexpected. Plus,
> > > in most cases, the "core" part of the VM is simply not very important.
> > > There just isn't much code there -- JamVM is 20KLOC, anybody could
> > > comfortably rewrite this.
> >
> >
> > Hmmm, well I used to work with the author of JamVM (Rob Lougher) and 
> he's
> > one of the brightest guys I know. I think you'll find that the low LOC
> > figure is testament to his ability to write lean code rather than an
> > indication of how easy it is to knock off a JVM on a wet Sunday 
> afternoon.
> >
> > BTW has anyone asked Rob about donating JamVM to Harmony? As the 
> (currently)
> > sole owner he should have no problem with switching licenses.
> >
> > Cheers,
> >
> > Dave
> >
> >
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 



-- 
If you want a GMail account, send me an E-Mail.

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Stefano Mazzocchi]

Mark Brooks wrote:
>> My point was that instead of attempting to disenfranchise one or the
>> other camp of its notions, allow two parallel veins of investigation
>> according each his own inclination.
> 
> 
> Investigation is fine enough, but let's face facts.  This is a HUGE
> project.
> 
> We do NOT have the time or manpower to write two VMs as part of a
> project where we need a working J2SE 5 implementation, from basement to
> TV aerial so to speak, and we need it in time to be relevant.  Even with
> donated code, it won't work to do VMs in parallel.

Look around: do you really think manpower is your scarcity point?

-- 
Stefano.

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)

[Stefano Mazzocchi]

Tom Tromey wrote:

>> Does anybody know if GCC allows such a thing?

>It already exists -- you're describing gcj.

on another email, he wrote:

> You can use gcj-as-jit right now, today, if you want, though it has
> some scalability problems.

o, ok [I should really do my homework]

People, as you probably already understand, being focused on web stuff,
Apache attracted pools of people (ourselves mentors included) that know
very very little about compilers and VMs.

As you might or might not know, this should not scare you: our intent
for harmony was done, exactly, to attract that pool of talents, from the
free java world, the academic world and the not-really-GPL-loving
industrial world.

If the mentors of this project were to write a JVM themselves, it would
be a piece of crap :-) So, consider our comments a way to stir the pot,
rather than a way to provide technical direction: with their mentor hats
on, nobody here will ever provide/dictate/mandate a technical decision,
that is left to the community. We will just try to lubricate the social
process (hopefully mostly in the background, to avoid getting in the
way) so that the technical one can advance more smoothly.

So, in short, I apologize in advance for our eventual cluelessness or
ignorance on the existing free/open java implementation or approaches.

-- 
Stefano.

Re: JIRA and SVN

[Davanum Srinivas]

David,

please feel free to ping Rob. It would be great!

thanks,
dims

On 5/21/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> On 20 May 2005 17:54:11 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> >
> >
> > This is too vague -- we don't know much about the unexpected. Plus,
> > in most cases, the "core" part of the VM is simply not very important.
> > There just isn't much code there -- JamVM is 20KLOC, anybody could
> > comfortably rewrite this.
> 
> 
> Hmmm, well I used to work with the author of JamVM (Rob Lougher) and he's
> one of the brightest guys I know. I think you'll find that the low LOC
> figure is testament to his ability to write lean code rather than an
> indication of how easy it is to knock off a JVM on a wet Sunday afternoon.
> 
> BTW has anyone asked Rob about donating JamVM to Harmony? As the (currently)
> sole owner he should have no problem with switching licenses.
> 
> Cheers,
> 
> Dave
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: mudGE VM (was RE: Developing Harmony)

[Steven Gong]

On 5/20/05, Nick Lothian <[EMAIL PROTECTED]> wrote:
> 
> Try "mudGE VM".
> 
> The link is www.mudge.nl/java/ 
> 
Oh, it needs m$ vs.net  :(
-- 
Best Regards
Steven Gong

Re: JIRA and SVN

[David Griffiths]

On 20 May 2005 17:54:11 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> 
> 
> This is too vague -- we don't know much about the unexpected. Plus,
> in most cases, the "core" part of the VM is simply not very important.
> There just isn't much code there -- JamVM is 20KLOC, anybody could
> comfortably rewrite this.


Hmmm, well I used to work with the author of JamVM (Rob Lougher) and he's 
one of the brightest guys I know. I think you'll find that the low LOC 
figure is testament to his ability to write lean code rather than an 
indication of how easy it is to knock off a JVM on a wet Sunday afternoon.

BTW has anyone asked Rob about donating JamVM to Harmony? As the (currently) 
sole owner he should have no problem with switching licenses.

Cheers,

Dave

Re: JIRA and SVN

[usman bashir]

These are good thikning and i have few things more to add up.
 first i think it will be better that we select a base architecture that is 
completely based upon harmony rather then acquiring from other sides. then 
what we can do ,we can took one two or even three VMS and incoperate them 
with different target environments (i mean embeded, dektop,server) it will 
help us to also seee the performance issues but also allow us to work in 
parrallel in different areas.
 and now the question is how it could be done, one thing i m sure that we 
have guys from different enviornments like some from embeded culture and 
some from tradationals so we should split the work according their nature.
 altough it seem more vauge but i think we try to get few things on these 
lines.

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



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

Re: timeframe for mid-level decissions

[Jakob Praher]

hi Geir,

Geir Magnusson Jr. wrote:
> 
> On May 19, 2005, at 8:18 AM, Jakob Praher wrote:
>> Geir Magnusson Jr. wrote:
>>> On May 19, 2005, at 5:24 AM, Jakob Praher wrote:
>>>
>>> Both of these are conventional expectations, and we can meet this via
>>> pluggability, right?
>>>

If you have for instance completly different object layouts, caching
mechanisms, method lookup, then pluggablity becomes difficult. We are
talking about high performance stuff - so it should't get too much
wrapping - except for #ifdefs (also jikes rvm has this sort of stuff in
java :-)).
One thing that should be in common are the intermediate representations
- see below.

What would be interesting is to implement method lookup based on
hashing (java signatures are strings as well), with inline caching based
on hashes (not vtables) and then compare the result with a vtable
approach, which in Java must also be built at load time. The
self/smalltalk/... community has proven that this can be done quite
efficient and gives you a whole lot of flexibility - speaking of "hot
swapping" for instance, or implementing scripting langauge on top of it.


>>>
>> Depends on the divergence of the 2 systems. If for instance you have 2
>> vms (eg. one in jave for server and one in c/c++ for client then  IMHO it
>> would be better to make two separate projects). These two vms wouldn't
>> have much in common.
> 
> That's sort of true. :)
> 
> I'd agree that they would be separate efforts, but there's no reason 
> why they couldn't be in the same Apache Harmony community.  For 
> example, look at the Apache Logging communty- there are alternate 
> language implementations of the same functionality.
> 
> I'd want to keep things close, as we do want to be able to share things.
>
Yes thats sort of clear. Since its likely that harmony is becoming
top-level project, these projects should definitely go under the
"harmony roof".

What I was trying to say with LLVM is that you could implement exactly
that. You have a spec, a MIR, ... . So you implement one VM/Compiler in
Java and the other in C/C++ - you get the advantage of sticking to the
same specs and could also reuse some of the portions - for instance the
dynamic compiler, after the C implementation has bootstrapped the VM and
set up the execution environment, it can compile itself using in Java.
This also works with other MIRs. But to make sure: Build on something
that was already specified nicely (like LLVM for instance) and extend
that specs to fix things. (More evolutionary). I think starting with a
whole new IR spec and stuff would be much work.


>>>
>> Ok. It's only for me to get an understanding of the projects identity.
>> Yes thats probably true especially since we - as opposed to the closed
>> source vms - don't have business interest in keeping secrets about  inner
>> layouts.
> 
> 
> Right - we're forming our identity as we do this.  Patience :)
>
:-)

> 
> 
> I want to use APR to *implement* our platform interfacing layer, but  I
> have no idea if APR is the right *definition* of the API for OS 
> interfacing.  I'd rather not presume an API until we understand  what's
> required by the VM.
> 
Ok. APR is quite interesting as a low level abstraction layer. And its
favourable because it is a very low layer. Too much abstraction from the
OS is probably more problematic then having some modules implemented for
different OSes clearly.
> 
> 
> Much more :)
> 
Yes, much more is in my head.

counter question:
What's your favorable VM technology - I've heard on the list that a VM
might be contributed - what should that mean?

--Jakob

Re: MIT compiler course

[usman bashir]

It is always awsome moro for the people living in this part of world (i mean 
South Asia) becuase of our unability to attend that top univeristy.
 thnx a lot andy

 On 5/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 
> 
> Bryce Leo wrote:
> 
> >Great find, can that be added to the wiki under Bookmarks?
> >
> >
> >
> Sure. Do it.
> 
> --
> Andrew C. Oliver
> SuperLink Software, Inc.
> 
> Java to Excel using POI
> http://www.superlinksoftware.com/services/poi
> Commercial support including features added/implemented, bugs fixed.
> 
> 


-- 
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: timeframe for mid-level decissions

[Jakob Praher]

hi Tom,

Tom Tromey wrote:
>>"Jakob" == Jakob Praher <[EMAIL PROTECTED]> writes:
> 
> 
> Jakob> do we want to build something that competes with sun j2se/mono on the
> Jakob> desktop side (gnome/redhat would be interested in that)
> 
> I don't speak for Red Hat, but I can explain a little about why we
> ship gcj and not other VMs.  In addition to all our in house history
> with gcc and gcj, it basically boils down to 3 things:
> 
> 1. Platform coverage.  The solution has to work on at least whatever
> platforms Fedora Core and RHEL work on.
> 
> 2. Performance.  The result has to be reasonable competitive
> performance wise.  E.g., starting eclipse has to be reasonable both in
> time and space.
How are doing with gcj in this direction?
> 
> 3. Debugging.  There has to be some debugger story.
> 
> Harmony would have to excel on all of these before I would even
> consider, say, recommending it for FC.
>
These are important points.
I think that the 2 platforms should be interoperable. So probably many
installations will use gcj soon.(at least if its the default for fedora)
Especially for UI stuff it would be really interesting to get
interoperability right. IMHO harmony should be ably to understand the
gcj abi and the so cache, which is right now at the very heart of gcj.
Perhaps a second implementation of that would lead to more specification
  which would have positive results on gcj too.


-- Jakob