You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by theUser BL <th...@hotmail.com> on 2005/05/12 13:17:19 UTC
Against using Java to implement Java (Was: Java)
I hope you use C to write the VM for Harmony.
The reason is, that I think, that the best is, if Harmony is nearly 100%
compatible to Suns Java.
If you write the VM in Java itself, then there existing some problems:
1. you need a native-code compiler (like gcj) to create it. And if Harmony
itself is a native-code compiler it is not 100% compatible to Suns JVM.
2. I don't know how you want to create a JNI-Interface for C, if the JVM is
written in Java.
3. The best would be, if all *.DLL (on Windows) and *.so (on
Linux/Unix/MacOSX) files are like Suns one. For example: Older J2SEs used
Symmantecs JITter. And it is possible that there existing firms which try to
replace also some other parts of Java with its own one. So it would be nice,
if then Harmony can use this replacements, too.
Greatings
theuserbl
Re: Against using Java to implement Java (Was: Java)
Posted by Stefano Mazzocchi <st...@apache.org>.
theUser BL wrote:
> I hope you use C to write the VM for Harmony.
>
> The reason is, that I think, that the best is, if Harmony is nearly 100%
> compatible to Suns Java.
>
> If you write the VM in Java itself, then there existing some problems:
> 1. you need a native-code compiler (like gcj) to create it.
No, a java JVM can run itself, it only need a tiny native bootstrapper.
> And if
> Harmony itself is a native-code compiler it is not 100% compatible to
> Suns JVM.
eh? that is simply not true: the TCK is a functional test not an
architectural one.
> 2. I don't know how you want to create a JNI-Interface for C, if the JVM
> is written in Java.
'written in java' doesn't mean that it doesn't have access to the
underlying OS, it has to. Writing a JVM that needs another JVM to run
would be stupid :-)
> 3. The best would be, if all *.DLL (on Windows) and *.so (on
> Linux/Unix/MacOSX) files are like Suns one. For example: Older J2SEs
> used Symmantecs JITter. And it is possible that there existing firms
> which try to replace also some other parts of Java with its own one. So
> it would be nice, if then Harmony can use this replacements, too.
Modularity is something we aim at for Harmony.
--
Stefano.
Re: Against using Java to implement Java (Was: Java)
Posted by Davanum Srinivas <da...@gmail.com>.
Ravi,
can you please add the link to the wiki as well.
thanks,
dims
On 5/14/05, Ravi kiran Gorrepati <ra...@cs.unm.edu> wrote:
> Check the design of Jikes at,
> http://www.research.ibm.com/journal/sj/391/alpern.pdf
>
> Though the memory subsytem section is a little outdated,
> that should not prevent you from understanding how it
> works.
>
> --
> Ravi
>
> On Thu, 12 May 2005 10:30:12 -0600, <tu...@mac.com> wrote:
>
> >
> > On 12 May 2005, at 12:17, theUser BL wrote:
> >
> >> I hope you use C to write the VM for Harmony.
> >>
> >
> > Forgive me if I am repeating what others have already said - I'm a bit
> > late to this.
> >
> > Bootstrapping the whole thing in Java is a very clever idea, but what
> > about the management of the heap (GC etc)? Presumably that would have to
> > be done in some layered system, with a very simplistic GC in the
> > bootstrap VM, with layers of extra logic on top of it? Or am I missing
> > something?
> >
> > If so, what sort of performance hit would this have? I agree that in
> > many ways it is a Good Thing, but so was Sun's handle redirection stuff
> > (where an object reference referred to a table, that referred to the
> > object) but Microsoft's Bad Way of simply linking to the object ran much
> > quicker. In fact, didn't Sun eventually switch to that way of working? I
> > think there was something about it in Simon Ritter's talk on GC at last
> > year's London Java Tech days.
> >
> > I know very little about all this (so please beat me only with a very
> > small stick and in a loving manner) but would it be possible to start
> > with an existing(?) JVM written in C/C++ and then start to migrate it
> > part by part into Java? Taking the baby steps approach, couldn't we work
> > out exactly where the log-jams are likely to be? And then get as much as
> > we can in Java, so long as it doesn't have a significant impact on
> > performance?
> >
> > Would taking the C/C++ --> Java approach mean that we could base our
> > discussions upon the evidence of the code, and less upon subjective
> > belief? More ground up and less BUFD?
> >
> > DG
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
stop the bus
Posted by Aaron Hamid <ar...@cornell.edu>.
[I am deluged by harmony-dev email so forgive me if I cannot cite and respond to individuals, er, individually]
Writing a VM from scratch? Making it a generic VM with it's OWN bytecode set? Inventing a new language!?
Hold on.
I don't think this project has much chance of success at all unless it embraces the existing communities of talented and dedicated developers that have already spent YEARS pouring effort into existing projects. I think rewriting from scratch is a total non-starter. It's just going to alienate the very communities which are the only fuel this project has. I don't think it is at all "clear" in the proposal that Harmony should write everything from scratch ("We will create directly, via inclusion of independent third-party code, or through contribution"). Instead of armchair opinions on VM architecture by idle onlookers (which includes me), I would much rather hear from members of the communities already mentioned (and I know many have already spoken), on what *they* would like out of the project. I think the best idea is to come to a compromise, or middle ground (perhaps manifested by some initial set of interfaces, and donated implementations of those interfaces), that a
ll parties can accept and work towards. In such a large project as this, I think the limiting factor is not great ideas, or even skilled individual coders, but community interest and devotion, and we really have to harness the existing interest and talent out there. With such a community we can always fix a less-than-optimal initial implementation...but without it we are going nowhere. Even if Harmony doesn't produce one line of original code (I doubt that will be the case anyway), I think it would be immensely useful to at least unite the existing projects, and give them a common direction. From the links I've followed so far, I am very impressed with the progress GCJ, Classpath, Kaffe, and other have made, and the fact that I was not even aware of this progress, despite having done Java development for years, I think indicates that Harmony certainly has a large potential role to play in advocacy.
The only clear thing I see at this point is:
* Classpath should be used as the class library.
Does anybody disagree that reusing this code base is the only feasible way to move forward? I think having to rewrite the class library from scratch would set us back years, so hopefully that is off the table. It looks like both parties involved are, or will be soon, coming to an amicable legal resolution, so hopefully this is a moot issue.
I am sure discussions are happening in parallel between various projects (especially because this list is so noisy). Hopefully we can come to some sort of middle ground that is acceptable by all parties, and takes advantage of all the work already done.
There already appears to be cooperation between GCJ, Kaffe, and Classpath, including various forks thereof. Can the VM parts of GCJ and Kaffe be reconciled, or modularized based on common interfaces? What are the fourth, fifth, and sixth largest free Java efforts, if that can even be quantified? Are the JikesRVM architecture decisions incompatible with GCJ and Kaffe design? Besides the class library, what portions of existing implementations are those projects willing to "give up" to a third party?
Aaron Hamid
Re: Against using Java to implement Java (Was: Java)
Posted by Ravi kiran Gorrepati <ra...@cs.unm.edu>.
Check the design of Jikes at,
http://www.research.ibm.com/journal/sj/391/alpern.pdf
Though the memory subsytem section is a little outdated,
that should not prevent you from understanding how it
works.
--
Ravi
On Thu, 12 May 2005 10:30:12 -0600, <tu...@mac.com> wrote:
>
> On 12 May 2005, at 12:17, theUser BL wrote:
>
>> I hope you use C to write the VM for Harmony.
>>
>
> Forgive me if I am repeating what others have already said - I'm a bit
> late to this.
>
> Bootstrapping the whole thing in Java is a very clever idea, but what
> about the management of the heap (GC etc)? Presumably that would have to
> be done in some layered system, with a very simplistic GC in the
> bootstrap VM, with layers of extra logic on top of it? Or am I missing
> something?
>
> If so, what sort of performance hit would this have? I agree that in
> many ways it is a Good Thing, but so was Sun's handle redirection stuff
> (where an object reference referred to a table, that referred to the
> object) but Microsoft's Bad Way of simply linking to the object ran much
> quicker. In fact, didn't Sun eventually switch to that way of working? I
> think there was something about it in Simon Ritter's talk on GC at last
> year's London Java Tech days.
>
> I know very little about all this (so please beat me only with a very
> small stick and in a loving manner) but would it be possible to start
> with an existing(?) JVM written in C/C++ and then start to migrate it
> part by part into Java? Taking the baby steps approach, couldn't we work
> out exactly where the log-jams are likely to be? And then get as much as
> we can in Java, so long as it doesn't have a significant impact on
> performance?
>
> Would taking the C/C++ --> Java approach mean that we could base our
> discussions upon the evidence of the code, and less upon subjective
> belief? More ground up and less BUFD?
>
> DG
Re: Against using Java to implement Java (Was: Java)
Posted by tu...@mac.com.
On 12 May 2005, at 12:17, theUser BL wrote:
> I hope you use C to write the VM for Harmony.
>
Forgive me if I am repeating what others have already said - I'm a
bit late to this.
Bootstrapping the whole thing in Java is a very clever idea, but what
about the management of the heap (GC etc)? Presumably that would have
to be done in some layered system, with a very simplistic GC in the
bootstrap VM, with layers of extra logic on top of it? Or am I
missing something?
If so, what sort of performance hit would this have? I agree that in
many ways it is a Good Thing, but so was Sun's handle redirection
stuff (where an object reference referred to a table, that referred
to the object) but Microsoft's Bad Way of simply linking to the
object ran much quicker. In fact, didn't Sun eventually switch to
that way of working? I think there was something about it in Simon
Ritter's talk on GC at last year's London Java Tech days.
I know very little about all this (so please beat me only with a very
small stick and in a loving manner) but would it be possible to start
with an existing(?) JVM written in C/C++ and then start to migrate it
part by part into Java? Taking the baby steps approach, couldn't we
work out exactly where the log-jams are likely to be? And then get as
much as we can in Java, so long as it doesn't have a significant
impact on performance?
Would taking the C/C++ --> Java approach mean that we could base our
discussions upon the evidence of the code, and less upon subjective
belief? More ground up and less BUFD?
DG
Re: Against using Java to implement Java (Was: Java)
Posted by Davanum Srinivas <da...@gmail.com>.
Sounds great Robin. So what the the problems (if any) with JikesRVM?
how would one go about making it enterprise-ready (to use a well-worn
cliche)?
thanks,
dims
On 5/12/05, Robin Garner <ro...@anu.edu.au> wrote:
> > I hope you use C to write the VM for Harmony.
> >
> > The reason is, that I think, that the best is, if Harmony is nearly 100%
> > compatible to Suns Java.
> >
> > If you write the VM in Java itself, then there existing some problems:
> > 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> > itself is a native-code compiler it is not 100% compatible to Suns JVM.
>
> This isn't necessarily so. While there are bootstrapping issues, VMs like
> JikesRVM compile themselves under normal operation.
>
> > 2. I don't know how you want to create a JNI-Interface for C, if the JVM
> > is
> > written in Java.
>
> This has been done successfully by existing Java-in-Java virtual machines.
> JikesRVM is open source - you could read the code and find out how it
> does it if you want :)
>
> cheers,
> Robin
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Against using Java to implement Java (Was: Java)
Posted by Robin Garner <ro...@anu.edu.au>.
> I hope you use C to write the VM for Harmony.
>
> The reason is, that I think, that the best is, if Harmony is nearly 100%
> compatible to Suns Java.
>
> If you write the VM in Java itself, then there existing some problems:
> 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> itself is a native-code compiler it is not 100% compatible to Suns JVM.
This isn't necessarily so. While there are bootstrapping issues, VMs like
JikesRVM compile themselves under normal operation.
> 2. I don't know how you want to create a JNI-Interface for C, if the JVM
> is
> written in Java.
This has been done successfully by existing Java-in-Java virtual machines.
JikesRVM is open source - you could read the code and find out how it
does it if you want :)
cheers,
Robin
Re: Against using Java to implement Java (Was: Java)
Posted by Bob <ci...@earthlink.net>.
On May 12, 2005, at 7:17 AM, theUser BL wrote:
> I hope you use C to write the VM for Harmony.
GCJ would suit all the concerns you listed. In many ways, GCJ can be
thought of as "C++ in Java syntax, plus a nice runtime library". GCJ
can load .dll/.so files, etc (using extensions to the standard Java
language).
Re: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
Nookala Satish Kumar wrote:
> I too support the point to implement the VM in C/C++. But the problem
> with this would be porting the VM to multiple platforms like *nix,
> Win32, Mac etc.
>
> Hence we have to choose between the two: Performance and Portability.
We do? Httpd runs on _far_ more platforms than Java does. It's written in C.
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: Against using Java to implement Java (Was: Java)
Posted by Nookala Satish Kumar <no...@gmail.com>.
I too support the point to implement the VM in C/C++. But the problem
with this would be porting the VM to multiple platforms like *nix,
Win32, Mac etc.
Hence we have to choose between the two: Performance and Portability.
Regards,
Satish.
On 12/05/05, theUser BL <th...@hotmail.com> wrote:
> I hope you use C to write the VM for Harmony.
>
> The reason is, that I think, that the best is, if Harmony is nearly 100%
> compatible to Suns Java.
>
> If you write the VM in Java itself, then there existing some problems:
> 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> itself is a native-code compiler it is not 100% compatible to Suns JVM.
> 2. I don't know how you want to create a JNI-Interface for C, if the JVM is
> written in Java.
> 3. The best would be, if all *.DLL (on Windows) and *.so (on
> Linux/Unix/MacOSX) files are like Suns one. For example: Older J2SEs used
> Symmantecs JITter. And it is possible that there existing firms which try to
> replace also some other parts of Java with its own one. So it would be nice,
> if then Harmony can use this replacements, too.
>
> Greatings
> theuserbl
>
>
--
|| Satyam Vada, Dharmam Chara ||
|| Matru Devo Bhava, Pitru Devo Bhava ||
|| Acharya Devo Bhava, Atithi Devo Bhava ||
Get Firefox. The browser you can trust.
http://www.spreadfirefox.com/?q=affiliates&id=43194&t=1
Re: Against using Java to implement Java (Was: Java)
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi,
> I'd be interested in hearing more from Steve on how well that works
> within JikesRVM. From reading some papers on the web, it seems that
> the MMTk has been ported to other, non-Java runtimes as well, and I
> guess that this binding-vm-components-via-java-interfaces problem has
> been efficiently solved by other bright people already outside the
> pure-java-runtime space.
Actually Robin Garner is the expert, as he wrote his honors thesis on
the subject. http://eprints.anu.edu.au/archive/00002397/ (MMTk was
previously known as JMTk---we dropped the 'J' to reflect our goals of
language neutrality).
The short answer is that it is easy enough to compile up the bulk of
MMTk into a library using gcj. However, for fine-grained interactions
(not an issue with a compiler, but a real issue with write barriers and
allocation sequences), one really does not want to go through a C->Java
transition each time. What one really wants is for the barrier and
allocation fast paths to be compiled into the user application code. In
a Java-in-Java system, this happens naturally and automatically (since
both the user app and the barrier are in Java and the compiler can
inline the barrier code trivially). Otherwise it is a little harder to
make this perform well. Exactly how one would approach it would depend
on how the compiler dealt with allocation sequences and barriers.
As to the broader issue of componentization etc, here's a very brief
overview. I will try to get a better technical write up available to
everyone soon...
The model is that MMTk has a reasonably well defined public interface,
which we think of in loose software engineering terms as its "features"
and "requirements", where the features are a much larger set than the
requirements. Likewise the host VM has features and requirements with
regards to memory management. We then build adaptors in each direction,
satisfying the MM requirments with that VM's features, and satisfying
the VM requirements with that MM's features. That glue code is
critical, but actually fairly modest. This is how Jikes RVM and MMTk
interact today, adn also how Rotor and (soon) jnode glue into MMTk too.
The glue code can be written under whatever license you like. You then
just link your VM against MMTk. The key to all of this (and this really
is the key!) is that the core of MMTk is strictly VM neutral and has no
VM-specific code in it whatsoever. This VM neutral core is clearly
separated, with all VM-specific code falling under a separate
sub-package (org.mmtk.vm) with well defined dummy classes. This means
MMTk is never "ported", rather one just writes a suitable adaptor. The
above only works once one has got the abstractions right.
I hope this helps.
--Steve
Re: Against using Java to implement Java (Was: Java)
Posted by Dalibor Topic <ro...@kaffe.org>.
Matthew French wrote:
> But I am still thinking that we can make it so that we have a choice of
> multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
> or whatever other language takes the authors fancy. I can see many valid
> reasons why we would want to do this, but the trick is getting it to work
> without adding enormous complexity.
What worked well for GNU Classpath, and in my opinion helped the
cambrian explosion of free runtimes happen, that we witnessed within GNU
Classpath in the last two years, was to use Java for the interfaces, and
let the VMs do their own marshalling to whatever language they use
internally.
I'd be interested in hearing more from Steve on how well that works
within JikesRVM. From reading some papers on the web, it seems that the
MMTk has been ported to other, non-Java runtimes as well, and I guess
that this binding-vm-components-via-java-interfaces problem has been
efficiently solved by other bright people already outside the
pure-java-runtime space.
> How is Classpath done? Is the bulk of the code implemented in C and
> wrapped in Java? Or is it Java with a thin C api?
The bulk is written in Java. The largest chunk of C in classpath is
fdlibm, I believe, which should be eventually kicked out and replaced by
VM interfaces to let the VMs optimize Math.*() operations internally any
way they want without having to maintiain their separate copy of
java.lang.Math.
cheers,
dalibor topic
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 13, 2005, at 5:06 AM, Matthew French wrote:
>
> But it seems to me the reason behind the wide range of alternate
> VM's is
> because each of these has a specific niche to fill. If Harmony is
> intended
> to bring these efforts together, then I would think that some
> "bloat" is
> inevitable. Not performance bloat, mind you, just added complexity.
>
I'd like to figure out if this can be solved with modularity - if
there are needs that can be met with just configuration of parts
rather than needs for a whole VM.
The problem is, I don't know :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Mark Brooks <jm...@hotmail.com>.
>Isn't it a good idea to write the first implementation in a functional
>programming language (read the wizard book)? That's what these
>platforms are designed for and the constructs are there to help in
>designing the thing. Then when you're happy you know what's good and
>bad you can re-code it in something that actually runs fast. I'm aware
>of a reasonable amount of literature that talks about GC and
>interpretation techniques that uses languages such as ML and Scheme.
Somebody else mentioned Erlang (because of its concurrency support?), and I
mentioned Ocaml, which is an ML variant.
I think your idea is a good one, but I don't think that will happen. First,
there's an entrenched base of people who think a declarative programming
style is just weird, period. They don't like it and don't want to do it.
Then there'd be the issue of what functional programming language to use.
At the end of the day, you have to have enough hands to do the work, and you
would be surprised how many willing workers have never had exposure to
functional programming.
If we were to go the route of writing the prototype in a functional
programming language, I'd suggest ANSI Common Lisp. There are a lot of
LISPers out there (and Schemers), and LISP has features that make bottom-up
rapid development very doable. There are a lot of free and open-source
Common LISP implementations as well. SBCL, CMU-CL, CLISP, GCL, OpenMCL,
blah blah blah, and of course there's the commercial stuff like Allegro CL
and LispWorks. With its macro facility, ACL codebases can become their own
lanaguages.
ML/Ocaml is good too. I'd actually recommend Ocaml over ML because it has
seen actual commercial use in Europe (although SML has been used in
England).
I don't know enough about Erlang. Clean looks interesting, and Mozart looks
pretty interesting too, but then we are getting into niche languages that
almost nobody who would be interested in this project would know that much
about.
Heck, prototype it with Jython. :)
>Compiled Java initially seems as good as anything, but don't those
>compilers add in their own brand of GC? Wouldn't that be an overhead
>we neiter need nor want? Do we want to generate our own native
>compiler? I'm thinking the best native compiler/language to use is
>probably C.
We've got people here from Redhat, so they are probably thinking that
provide a back-end to GCJ would fit that need.
>I agree that most of the libraries can be written in Java, but
>wouldn't that constitute a separate apache project, just like GNU
>Classpath? The VM should probably be as clean as a very clean thing...
>in a clean room.. (hence why I never mentioned C++ :)
I suspect that since we need both to pass the TCK, we will have two projects
in one. I think that the class libraries will be the bigger part of the
work.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Against using Java to implement Java (Was: Java)
Posted by Steve Heath <st...@gmail.com>.
Isn't it a good idea to write the first implementation in a functional
programming language (read the wizard book)? That's what these
platforms are designed for and the constructs are there to help in
designing the thing. Then when you're happy you know what's good and
bad you can re-code it in something that actually runs fast. I'm aware
of a reasonable amount of literature that talks about GC and
interpretation techniques that uses languages such as ML and Scheme.
Compiled Java initially seems as good as anything, but don't those
compilers add in their own brand of GC? Wouldn't that be an overhead
we neiter need nor want? Do we want to generate our own native
compiler? I'm thinking the best native compiler/language to use is
probably C.
I agree that most of the libraries can be written in Java, but
wouldn't that constitute a separate apache project, just like GNU
Classpath? The VM should probably be as clean as a very clean thing...
in a clean room.. (hence why I never mentioned C++ :)
On 5/13/05, Matthew French <ma...@camary.co.za> wrote:
> Mark Brooks said:
> > The chief objection I have to using C to write the VM is that it
> > introduces a host of common errors and delays associated with
> > using C or C++ for large products. C is an excellent language
> > for its purposes, but this isn't 1972.
>
> Hmmm. First I would argue that a VM is not a big project. Extraordinarily
> complex, yes. But not big.
>
> Secondly, the common errors and problems related to C usually are the
> result of pointers, memory management and complexity. But I don't see how
> we can get away from these using Java. The whole point of using a VM is to
> hide this functionality from the application, which means by definition we
> have to implement it in the VM.
>
> Then Bob said:
> >>> IMHO both JITs and pre-compiling have their place.. it
> >>> depends on the application whether one is definitely better
> >>> than the other.
> >
> > This is a recipe for a bloated system that never works.
>
> Agreed. Which is why we should try and avoid bloat. :)
>
> But it seems to me the reason behind the wide range of alternate VM's is
> because each of these has a specific niche to fill. If Harmony is intended
> to bring these efforts together, then I would think that some "bloat" is
> inevitable. Not performance bloat, mind you, just added complexity.
>
> My hope is that by clamping down on this complexity early [did I mention
> architecture? :) ] we will not only remove the bloat but make the task
> even less complex than it is now. (FWIW: I am working on a document, but
> it has taken on a life of its own. Hope to finish over the weekend)
>
> > Also, most app
> > programmers don't want to worry about the details of how their program
> > is compiled.
>
> This is dangerous territory: a person who does not know how their car
> moves will eventually run out of petrol.
>
> Java users, whether they like it or not, will eventually be confronted
> with some implementation details. Our role should be to make such issues
> transparent, not hide them. By doing so we would be reducing the time and
> effort to resolve such issues.
>
> This does not mean someone needs to read a 200 page tome just to run Java.
> Hopefully the quick start guide will contain just one line...
>
> Ben Laurie said:
> > Mark Brooks wrote:
> >>> I hope you use C to write the VM for Harmony.
> >
> > I've tried to sell C++ in the ASF many times. Even back when it wasn't
> > quite so bloated as it is now it wasn't a popular idea. Far fewer people
> > can write C++ than C, and hardly any of those can write _good_ C++.
> >
> > So, I think we'll end up back at C.
>
> As much as I like C++, I would have to agree that C should be the default.
>
> But I am still thinking that we can make it so that we have a choice of
> multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
> or whatever other language takes the authors fancy. I can see many valid
> reasons why we would want to do this, but the trick is getting it to work
> without adding enormous complexity.
>
> > As I've said before, I'd like to see
> > a framework that _allows_ most of the VM to be run in Java (or Python,
> > or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
>
> The bulk of a Java environment is the API/libraries. I would like to see
> the libraries written in Java as much as possible. For example, LDAP
> functionality can be written entirely in Java. You just need to talk the
> right binary language.
>
> Same applies to parts of the maths API like BigDecimal, date functionality
> (except some cases like getting the system date), XML classes, the bulk of
> the IO classes, etc. We should rely on the VM to optimise the Java code -
> I see no reason why an efficient VM cannot match C code or assembler in
> most cases.
>
> There are exceptions: for example, advanced maths like sin() or a bulk
> block copy will perform much better using hardware. Even then, I think it
> could be useful to have implementations of these functions written in
> Java, and the ability to override them.
>
> How is Classpath done? Is the bulk of the code implemented in C and
> wrapped in Java? Or is it Java with a thin C api?
>
> - Matthew
>
>
Re: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
Matthew French wrote:
> Ben Laurie said:
>
>>Mark Brooks wrote:
>>
>>>>I hope you use C to write the VM for Harmony.
>>
>>I've tried to sell C++ in the ASF many times. Even back when it wasn't
>>quite so bloated as it is now it wasn't a popular idea. Far fewer people
>>can write C++ than C, and hardly any of those can write _good_ C++.
>>
>>So, I think we'll end up back at C.
>
>
> As much as I like C++, I would have to agree that C should be the default.
>
> But I am still thinking that we can make it so that we have a choice of
> multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
> or whatever other language takes the authors fancy. I can see many valid
> reasons why we would want to do this, but the trick is getting it to work
> without adding enormous complexity.
>
>
>>As I've said before, I'd like to see
>>a framework that _allows_ most of the VM to be run in Java (or Python,
>>or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
>
> The bulk of a Java environment is the API/libraries. I would like to see
> the libraries written in Java as much as possible. For example, LDAP
> functionality can be written entirely in Java. You just need to talk the
> right binary language.
I'm not arguing with that, I'm talking about the VM, not the libraries.
> Same applies to parts of the maths API like BigDecimal, date functionality
> (except some cases like getting the system date), XML classes, the bulk of
> the IO classes, etc. We should rely on the VM to optimise the Java code -
> I see no reason why an efficient VM cannot match C code or assembler in
> most cases.
>
> There are exceptions: for example, advanced maths like sin() or a bulk
> block copy will perform much better using hardware. Even then, I think it
> could be useful to have implementations of these functions written in
> Java, and the ability to override them.
BigDecimal is an exception, too, if you want to do serious crypto. So is
all the rest of the crypto.
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: Against using Java to implement Java (Was: Java)
Posted by Matthew French <ma...@camary.co.za>.
Mark Brooks said:
> The chief objection I have to using C to write the VM is that it
> introduces a host of common errors and delays associated with
> using C or C++ for large products. C is an excellent language
> for its purposes, but this isn't 1972.
Hmmm. First I would argue that a VM is not a big project. Extraordinarily
complex, yes. But not big.
Secondly, the common errors and problems related to C usually are the
result of pointers, memory management and complexity. But I don't see how
we can get away from these using Java. The whole point of using a VM is to
hide this functionality from the application, which means by definition we
have to implement it in the VM.
Then Bob said:
>>> IMHO both JITs and pre-compiling have their place.. it
>>> depends on the application whether one is definitely better
>>> than the other.
>
> This is a recipe for a bloated system that never works.
Agreed. Which is why we should try and avoid bloat. :)
But it seems to me the reason behind the wide range of alternate VM's is
because each of these has a specific niche to fill. If Harmony is intended
to bring these efforts together, then I would think that some "bloat" is
inevitable. Not performance bloat, mind you, just added complexity.
My hope is that by clamping down on this complexity early [did I mention
architecture? :) ] we will not only remove the bloat but make the task
even less complex than it is now. (FWIW: I am working on a document, but
it has taken on a life of its own. Hope to finish over the weekend)
> Also, most app
> programmers don't want to worry about the details of how their program
> is compiled.
This is dangerous territory: a person who does not know how their car
moves will eventually run out of petrol.
Java users, whether they like it or not, will eventually be confronted
with some implementation details. Our role should be to make such issues
transparent, not hide them. By doing so we would be reducing the time and
effort to resolve such issues.
This does not mean someone needs to read a 200 page tome just to run Java.
Hopefully the quick start guide will contain just one line...
Ben Laurie said:
> Mark Brooks wrote:
>>> I hope you use C to write the VM for Harmony.
>
> I've tried to sell C++ in the ASF many times. Even back when it wasn't
> quite so bloated as it is now it wasn't a popular idea. Far fewer people
> can write C++ than C, and hardly any of those can write _good_ C++.
>
> So, I think we'll end up back at C.
As much as I like C++, I would have to agree that C should be the default.
But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.
> As I've said before, I'd like to see
> a framework that _allows_ most of the VM to be run in Java (or Python,
> or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
The bulk of a Java environment is the API/libraries. I would like to see
the libraries written in Java as much as possible. For example, LDAP
functionality can be written entirely in Java. You just need to talk the
right binary language.
Same applies to parts of the maths API like BigDecimal, date functionality
(except some cases like getting the system date), XML classes, the bulk of
the IO classes, etc. We should rely on the VM to optimise the Java code -
I see no reason why an efficient VM cannot match C code or assembler in
most cases.
There are exceptions: for example, advanced maths like sin() or a bulk
block copy will perform much better using hardware. Even then, I think it
could be useful to have implementations of these functions written in
Java, and the ability to override them.
How is Classpath done? Is the bulk of the code implemented in C and
wrapped in Java? Or is it Java with a thin C api?
- Matthew
Re: Against using Java to implement Java (Was: Java)
Posted by FaeLLe <mr...@gmail.com>.
I expected to get flamed for this.
Nice to see a postive healthy discussion :)
On 5/13/05, Kev Jackson <ke...@it.fts-vn.com> wrote:
>
>
> >Write code of what ? Based on what ?
> >
> >Nothing has been decided ! After all this still a proposal right ? This
> can
> >be rejected too :)
> >
> >
> >
> >
> My point exactly, nothing has been decided, perhaps it's time to make
> some decisions
>
> >The thing is how much later into the project will the change be decided ?
> >
> >What if the change we make due too Poor Planning (with two capital P's)
> >cause the entire work or majority of it till then to be discarded ?
> >
> >
> >
> Change isn't a bad thing. I think that the proposal is fairly clear,
> but the approach to take is currently unclear, hence all the noise on
> the mailing list (of which I'm especially guilty)
> >>
>
> 2) create a community-developed modular runtime (VM and class library)
> architecture to allow independent implementations to share runtime
> components, and allow independent innovation in runtime components
>
> <<
>
> I read this as build a better VM than HotSpot under the APL, *and* write
> the class libraries. I don't read this as take kaffe or JRVM or any
> other product and slap an Apache sticker and go faster stripes on it.
> The proposal seems to be clear about writing from scratch if it isn't
> then my bad.
>
> >Apache votes arent done by the developers it is done by the committe (or
> am
> >i wrong)
> >
> >
> >
> AFAIK wrong, at least on the other Apache projects I've worked on,
> anyone can make a proposal, and developers can vote, but the committers
> have veto status (correct me if I'm wrong on this).
>
> >Write a crude VM first, from scratch, using other VM's as guidance, but
> >
> >
> >>not incorporating code from other projects to avoid licensing issues.
> >>Yes []
> >>No []
> >>
> >>At least we can see what's happening
> >>
> >>
> >>
> >
> >No ?
> >
> >
> >
> >
> Ok, at least it's a start ;)
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Against using Java to implement Java (Was: Java)
Posted by Mark Brooks <jm...@hotmail.com>.
>My point exactly, nothing has been decided, perhaps it's time to make some
>decisions
Agreed.
>I read this as build a better VM than HotSpot under the APL, *and* write
>the class libraries. I don't read this as take kaffe or JRVM or any other
>product and slap an Apache sticker and go faster stripes on it. The
>proposal seems to be clear about writing from scratch if it isn't then my
>bad.
That was my original impression as well. Besides, as a practical matter,
rewriting an existing codebase doesn't necessarily save you time. It can do
the opposite, in fact, depending on the state of the codebase. Maintaining
somebody else's code is no picnic, and they might make assumptions in
developing their own codebase that don't apply in your project.
So I suggest that, with regards to the VM at least, it should be our own
cleanroom VM. Really, Harmony is three projects. First, we need a build
environment. Second, we need a conforming VM. Third, we need a class
library. I suspect three will be the biggest issue. The Java platform API
is huge.
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: Against using Java to implement Java (Was: Java)
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>Write code of what ? Based on what ?
>
>Nothing has been decided ! After all this still a proposal right ? This can
>be rejected too :)
>
>
>
>
My point exactly, nothing has been decided, perhaps it's time to make
some decisions
>The thing is how much later into the project will the change be decided ?
>
>What if the change we make due too Poor Planning (with two capital P's)
>cause the entire work or majority of it till then to be discarded ?
>
>
>
Change isn't a bad thing. I think that the proposal is fairly clear,
but the approach to take is currently unclear, hence all the noise on
the mailing list (of which I'm especially guilty)
>>
2) create a community-developed modular runtime (VM and class library)
architecture to allow independent implementations to share runtime
components, and allow independent innovation in runtime components
<<
I read this as build a better VM than HotSpot under the APL, *and* write
the class libraries. I don't read this as take kaffe or JRVM or any
other product and slap an Apache sticker and go faster stripes on it.
The proposal seems to be clear about writing from scratch if it isn't
then my bad.
>Apache votes arent done by the developers it is done by the committe (or am
>i wrong)
>
>
>
AFAIK wrong, at least on the other Apache projects I've worked on,
anyone can make a proposal, and developers can vote, but the committers
have veto status (correct me if I'm wrong on this).
>Write a crude VM first, from scratch, using other VM's as guidance, but
>
>
>>not incorporating code from other projects to avoid licensing issues.
>>Yes []
>>No []
>>
>>At least we can see what's happening
>>
>>
>>
>
>No ?
>
>
>
>
Ok, at least it's a start ;)
Re: Against using Java to implement Java (Was: Java)
Posted by FaeLLe <mr...@gmail.com>.
On 5/13/05, Kev Jackson <ke...@it.fts-vn.com> wrote:
>
>
> >
> >How are you wasting replying to emails and undertaking a discussion.
> >
> >
> >
> Undertaking discussion isn't bad by itself. But discussing things and
> producing nothing is. From these discussions that have already occured,
> I would have liked to see some resolution. "We are going to tackle x
> first, we are going to use y technology" etc.
>
> >If you think spending time on a good design phase is a waste of time on
> such
> >a massive project theres something wrong...
> >
> >
> hmm, nope I think spending time doing nothing is a waste of time on any
> project of any scale. Get code in the repo, get people contributing,
> gather some momentum.
Write code of what ? Based on what ?
Nothing has been decided ! After all this still a proposal right ? This can
be rejected too :)
Without that we are doing exactly what critics
> will point out - nothing but arm waving. Making a decision is
> important, we can change it later.
The thing is how much later into the project will the change be decided ?
What if the change we make due too Poor Planning (with two capital P's)
cause the entire work or majority of it till then to be discarded ?
Right now we aren't even at the
> design stage, so you can't say I'm against "good design" - I'm arguing
> for momentum on ideas and deciding what to approach first. Currently we
> have too many options, so I'm going to propose a vote (in the Apache
> way), just to clear away some of the debris:
Apache votes arent done by the developers it is done by the committe (or am
i wrong)
Write a crude VM first, from scratch, using other VM's as guidance, but
> not incorporating code from other projects to avoid licensing issues.
> Yes []
> No []
>
> At least we can see what's happening
>
No ?
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Against using Java to implement Java (Was: Java)
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>
>How are you wasting replying to emails and undertaking a discussion.
>
>
>
Undertaking discussion isn't bad by itself. But discussing things and
producing nothing is. From these discussions that have already occured,
I would have liked to see some resolution. "We are going to tackle x
first, we are going to use y technology" etc.
>If you think spending time on a good design phase is a waste of time on such
>a massive project theres something wrong...
>
>
hmm, nope I think spending time doing nothing is a waste of time on any
project of any scale. Get code in the repo, get people contributing,
gather some momentum. Without that we are doing exactly what critics
will point out - nothing but arm waving. Making a decision is
important, we can change it later. Right now we aren't even at the
design stage, so you can't say I'm against "good design" - I'm arguing
for momentum on ideas and deciding what to approach first. Currently we
have too many options, so I'm going to propose a vote (in the Apache
way), just to clear away some of the debris:
Write a crude VM first, from scratch, using other VM's as guidance, but
not incorporating code from other projects to avoid licensing issues.
Yes []
No []
At least we can see what's happening
Against using Java to implement Java (Was: Java)
Posted by FaeLLe <mr...@gmail.com>.
Hmm my mail got bounced,
*Symantec Mail Security detected that you sent a message containing
prohibited content (SYM:09556261464022074052)*
Subject of the message: Re: Against using Java to implement Java (Was:
Java)Recipient of the message: "harmony-dev@incubator.apache.org" <
harmony-dev@incubator.apache.org>
---------- Forwarded message ----------
From: FaeLLe <mr...@gmail.com>
Date: May 13, 2005 4:41 AM
Subject: Re: Against using Java to implement Java (Was: Java)
To: harmony-dev@incubator.apache.org
On 5/13/05, Kev Jackson <ke...@it.fts-vn.com> wrote:
>
>
> >
> > So speak up project lead(s). We are here. We are talking a lot, but
> > not much is happening. Order us about. Assign work. Let's get our
> > hands dirty. The likelihood is that there will be changes along the
> > way anyhow. There almost always are, and developers dedicated to the
> > project will simply have to adapt.
> >
> couldn't agree more, the more 'talking' happening here, the less
> progress seems to be made. The guys rant on bile blog had some points
> about people here talking and waiting for a code drop from
> IBM/Sun/whoever. I'd like to help on this I really would, but I need a
> direction, what are we doing here? Is it a glue classpath to kaffe to
> xxx? Is it a write everything from scratch? If we want to get started
> we need some code, without it we're just wasting everyone's time
How are you wasting replying to emails and undertaking a discussion.
If you think spending time on a good design phase is a waste of time on such
a massive project theres something wrong...
Kev
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Against using Java to implement Java (Was: Java)
Posted by FaeLLe <mr...@gmail.com>.
On 5/13/05, Kev Jackson <ke...@it.fts-vn.com> wrote:
>
>
> >
> > So speak up project lead(s). We are here. We are talking a lot, but
> > not much is happening. Order us about. Assign work. Let's get our
> > hands dirty. The likelihood is that there will be changes along the
> > way anyhow. There almost always are, and developers dedicated to the
> > project will simply have to adapt.
> >
> couldn't agree more, the more 'talking' happening here, the less
> progress seems to be made. The guys rant on bile blog had some points
> about people here talking and waiting for a code drop from
> IBM/Sun/whoever. I'd like to help on this I really would, but I need a
> direction, what are we doing here? Is it a glue classpath to kaffe to
> xxx? Is it a write everything from scratch? If we want to get started
> we need some code, without it we're just wasting everyone's time
How are you wasting replying to emails and undertaking a discussion.
If you think spending time on a good design phase is a waste of time on such
a massive project theres something wrong...
Kev
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 12, 2005, at 11:26 PM, Kev Jackson wrote:
>
>
>
>>
>> So speak up project lead(s). We are here. We are talking a lot,
>> but not much is happening. Order us about. Assign work. Let's
>> get our hands dirty. The likelihood is that there will be changes
>> along the way anyhow. There almost always are, and developers
>> dedicated to the project will simply have to adapt.
>>
>>
>>
> couldn't agree more, the more 'talking' happening here, the less
> progress seems to be made. The guys rant on bile blog had some
> points about people here talking and waiting for a code drop from
> IBM/Sun/whoever. I'd like to help on this I really would, but I
> need a direction, what are we doing here? Is it a glue classpath
> to kaffe to xxx? Is it a write everything from scratch? If we
> want to get started we need some code, without it we're just
> wasting everyone's time
>
It's been one (1) week. There's been lots of good conversation. We
have lots of things to explore. I wouldn't force the issue right
now. I'm happy to go w/ C/C++ or Java. I just want to understand
the trade-offs.
I'd like to be sure that :
a) this is modular
b) that it's *fast*
c) that it's maintainable
d) that it's portable
I've seen both Java and C++/C codebases that satisfy a - d :)
I'm hoping that we can start looking at a small modular VM - even
just a toy implementation that we can hook to GNU Classpath through
an interfacing API that we judge to be sufficient for any
implementation of VM _or_ class library.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>
> So speak up project lead(s). We are here. We are talking a lot, but
> not much is happening. Order us about. Assign work. Let's get our
> hands dirty. The likelihood is that there will be changes along the
> way anyhow. There almost always are, and developers dedicated to the
> project will simply have to adapt.
>
couldn't agree more, the more 'talking' happening here, the less
progress seems to be made. The guys rant on bile blog had some points
about people here talking and waiting for a code drop from
IBM/Sun/whoever. I'd like to help on this I really would, but I need a
direction, what are we doing here? Is it a glue classpath to kaffe to
xxx? Is it a write everything from scratch? If we want to get started
we need some code, without it we're just wasting everyone's time
Kev
Re: Against using Java to implement Java
Posted by David Griffiths <da...@gmail.com>.
Well that's the theory but I think you'll find in practice that real
JITs cheat and inline object allocation using their knowledge of the
GC internals.
And there is no way that a JIT is going to implement synchronized
methods by doing a "monitorEnter" function call!
Dave
On 5/18/05, shudo@computer.org <sh...@computer.org> wrote:
> There is an old document describing a JIT interface though ORP should
> be more advanced, for example, as having GC interface.
>
> The JIT Compiler Interface Specification
> http://java.sun.com/docs/jit_interface.html
>
> Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X
> implements this interface and it was modified a bit for J2SDK 1.2.
> There were actually multiple JIT compilers based on this JIT interface
> including Symantec JIT, OpenJIT, shuJIT and TYA.
>
> This interface is not enough to support advanced optimizations
> including adaptive compilation, which today's Sun's and IBM's runtimes
> do. Adaptive compilation needs cooperation by an interpreter (or a
> baseline compiler) and I am not sure whether it can be factored out
> from the JVM core.
>
> From: Tom Tromey <tr...@redhat.com>
>
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > David> written in C. One of it's API calls is to allocate a new object. How
> > David> is your JIT module going to produce code to use that API? Via a C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only. Then
> > this can be done by name. Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several). This only needs to be done once,
> > at startup.
> >
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it. ORP already solved these problems in a
> > fairly reasonable way.
>
> Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
>
Re: Against using Java to implement Java
Posted by sh...@computer.org.
There is an old document describing a JIT interface though ORP should
be more advanced, for example, as having GC interface.
The JIT Compiler Interface Specification
http://java.sun.com/docs/jit_interface.html
Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X
implements this interface and it was modified a bit for J2SDK 1.2.
There were actually multiple JIT compilers based on this JIT interface
including Symantec JIT, OpenJIT, shuJIT and TYA.
This interface is not enough to support advanced optimizations
including adaptive compilation, which today's Sun's and IBM's runtimes
do. Adaptive compilation needs cooperation by an interpreter (or a
baseline compiler) and I am not sure whether it can be factored out
from the JVM core.
From: Tom Tromey <tr...@redhat.com>
> David> Maybe a concrete example would help. Let's say you have a GC module
> David> written in C. One of it's API calls is to allocate a new object. How
> David> is your JIT module going to produce code to use that API? Via a C
> David> function pointer?
>
> Yes.
>
> One way is to mandate link- or compile-time pluggability only. Then
> this can be done by name. Your JIT just references
> '&harmony_allocate_object' in its source and uses this pointer
> in the code it generates.
>
> The other way is to have the JIT call some central function to get a
> pointer to the allocator function (or functions, in libgcj it turned
> out to be useful to have several). This only needs to be done once,
> at startup.
>
>
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it. ORP already solved these problems in a
> fairly reasonable way.
Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 17, 2005, at 5:51 AM, David Griffiths wrote:
> Maybe a concrete example would help. Let's say you have a GC module
> written in C. One of it's API calls is to allocate a new object. How
> is your JIT module going to produce code to use that API? Via a C
> function pointer?
>
This is a good example of what I was trying to get at. We'll need to
decide on one standard way that things interoperate, and let those
who which implementation freedom to deal with the impedance match.
geir
> Dave
>
> On 5/16/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>
>> I'd only be happy here if the performance hit to cross "framework"
>> and "module implementation" boundaries was borne by the *module*, not
>> the framework, so that we can get fast implementations via
>> homogeneous implementation language and let anyone who wants to use
>> other languages bear the cost of marshaling across the boundary.
>>
>> if we aren't performant, it won't be interesting to users and
>> innovators.
>>
>> geir
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Royce Ausburn <es...@gmail.com>.
> I think it's too slow to have the overhead of a function call for
> every object allocation. This is the cost of modularization. I doubt
> any of the mainstream JVMs you are competing with do this.
>
Given how java (Apple JVM on OS X tiger) seems to allocate a chunk of
memory when you first load it and only occasionally reallocate more
if I'm using alot of memory, I'd say that it gets around that
'external function call overhead' by allocating memory into its
internal heap and then using native (pure java) code to manage the
VM's memory. I've no idea though - I'm interested now!
How do they do it?
--Royce
Re: Against using Java to implement Java (Was: Java)
Posted by David Griffiths <da...@gmail.com>.
I know, but despite the subject line my original point was about the
problem of modularizing a VM written in C.
Cheers,
Dave
On 5/18/05, Steve Blackburn <St...@anu.edu.au> wrote:
> This subject has been covered in detail at least twice already.
>
> There is no need for any function call on the fast path of the
> allocation sequence. In a Java in Java VM the allocation sequence is
> inlined into the user code. This has considerable advantages over "a
> few lines of assembler". Aside from the obvious advantage of not having
> to express your allocator in assembler, using Java also compiles to
> better code since the code can be optimized in context (register
> allocation, constant folding etc), producing much better code than hand
> crafted assembler.
>
> However this is small fry compared to the importance of compiling write
> barriers correctly (barriers are used by most high performance GCs and
> are executed far more frequently than allocations). The same argument
> applies though. The barrier expressed in Java is inlined insitu, and
> the optimizing compiler is able to optimize in context.
>
> Modularization does not imply any of this.
>
> --Steve
>
>
> Weldon Washburn wrote:
>
> >On 5/18/05, David Griffiths <da...@gmail.com> wrote:
> >
> >
> >>I think it's too slow to have the overhead of a function call for
> >>every object allocation. This is the cost of modularization. I doubt
> >>any of the mainstream JVMs you are competing with do this.
> >>
> >>
> >Yes. I agree. A clean interface would have a function call for every
> >object allocation. However if the allocation code itself is only a
> >few lines of assemby, it can be inlined by the JIT. Using a moving
> >GC, it is possible to get the allocation sequence down to a bump the
> >pointer and a compare to see if you have run off the end of the
> >allocation area.
> >
> >
>
Re: [dev-tools] was Re: Against using Java to implement Java (Was: Java)
Posted by FaeLLe <mr...@gmail.com>.
So have to agree with Mark...........
Making a JVM in a .NET language this deserves a ......... LOL
Sorry if i sound out of order had to do it :s
On 5/19/05, Mark Brooks <jm...@hotmail.com> wrote:
>
> >If we are going to entertain writing most of the JVM in a type-safe
> >language, we should also consider the proposed ECMA C++/CLI. From
> >what I understand, it standardizes a form of type-safe C++. It has
> >the promise of keeping both the Java and C camps happy.
>
> Not really. First, it is a Microsoft thing, tied in with .NET. Second, we
> don't want to have to depend on a .NET runtime to get a Java runtime.
> Third, never try to implement a large and complex existing project in a
> brand new technology.
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Against using Java to implement Java (Was: Java)
Posted by Stefano Mazzocchi <st...@apache.org>.
Steve Blackburn wrote:
> Keeping a leading-edge
> JVM at the leading edge is a lot of work---this is a fast moving field.
Yes and I don't think anybody believes that is likely to go away even if
we manage to get Harmony off the ground.
At the same time, Apache shows in a number of project how distributed,
parallel collaboration, lazy consensus and incremental evolution can
normally lead to a more organic and optimized evolution of a software
project, means that it might not have the same amount of energy injected
in the system as a commercial venture, but being its efficiency higher,
the result can potentially be even faster than commercial venues.
For more info on why this is, see my presentation at OSCON04 on
"darwinian software development"
http://www.betaversion.org/~stefano/papers/oscon2004.pdf
--
Stefano.
Re: Against using Java to implement Java (Was: Java)
Posted by Steve Blackburn <St...@anu.edu.au>.
>Very interesting. Please point me to the web pages that show
>SpecJAppServer/JBB/JVM... numbers for Jikes.
>
>
I don't have a pointer for you. Jikes RVM numbers appear on shudo's
page. Unfortunately the IA32 performance is not stellar. It was not
that long ago that Jikes RVM was competitive with the IBM's commercial
VM on PPC, but as you probably know the commercial VM's have been
improving in leaps and bounds. Dave Grove has outlined a number of
improvements to the opt compiler which should give us a big boost. We
just don't have the legs to do it ourselves... Keeping a leading-edge
JVM at the leading edge is a lot of work---this is a fast moving field.
>I see some mention of "magic types". Does this work around the java
>verifier by coercing a reference pointer into a Java int and
>vice-versa? This could be done by calling a non-verifiable chunk of
>code written in Java. Something like "Object int2ref(int x);" and
>"int ref2obj(Object z)". The net result sort of "C++-izes" java
>without having to modify the language.
>
>
The use of the magic types is limited to VM code. This is currently
unenforced in Jikes RVM, but should be.
>If we are going to entertain writing most of the JVM in a type-safe
>language, we should also consider the proposed ECMA C++/CLI. From
>what I understand, it standardizes a form of type-safe C++. It has
>the promise of keeping both the Java and C camps happy.
>
>Regarding the inlining of assembly in the JIT. You point out that
>this code can be written in Java then fed to the JIT. Do you see any
>reason why this code can not be written in C/C++, C#, etc?
>
>
Yes. The advantage we're getting is that there is no impedence mismatch
between the user code and the language in which the barriers etc are
expressed in (both are Java). Thus the JIT can trivially inline the
barrier and optimize it, disolving any artificial boundary between user
and VM code. This depends entirely on the VM implementation lanaguage
and the source language being the same (Java in our case). Does this
make sense? You may find it useful to read our ICSE paper on building
MMTk in Java. The paper is dated now, but the key ideas remain unchanged.
Cheers,
--Steve
>
>
>On 5/18/05, Steve Blackburn <St...@anu.edu.au> wrote:
>
>
>>Hi Weldon,
>>
>>It seems we have similar experiences with modularity, you in ORP, me in
>>Jikes RVM and MMTk.
>>
>>
>>
>>>Elaborating on a previous comment about inlining allocation/write
>>>barrier sequences. First design step: the GC team hand optimizes an
>>>assembly sequence while making sure the functionality is absolutely
>>>correct. Second step: the JIT team blindly inlines the GC team's
>>>assembly code and starts doing performance analysis. Third step: the
>>>JIT team integrates the inline sequence(s) into the IR so that all the
>>>optimizations can be performed. Perhaps these steps are the same for
>>>both a JVM written in Java as well as C/C++.
>>>
>>>
>>>
>>>
>>No. It is as I stated in the post to which you were responding. In
>>MMTk, we express the barriers and allocation sequences in Java and then
>>the opt compiler inlines them and optimizes them. The first Jikes RVM
>>collectors used assembler for the barriers, but we transitioned to
>>expressing them in Java a long time ago. This gives us much greater
>>expressibility on the GC side of the fence, greater portability (MMTk is
>>totally architecture neutral), and better performance because it
>>presents better opportunities for optimization to the compiler (constant
>>folding etc etc).
>>
>>
>>
>>>I am curious if a JVM written in Java must break type-safety. Does
>>>anyone know? For example, the "new" bytecode will need to manipulate
>>>(gasp!) raw "C" pointers. In specific, Java code will need to
>>>scribble on free memory to slice off "X" untyped bytes and return a
>>>raw pointer to the base of chunk of memory. Then the java code will
>>>need to use the raw pointer to install stuff like a vtable pointer.
>>>Once the object is setup, the Java code can revert to running code
>>>that can actually be verified. Also does anyone know the current
>>>state of research on formally proving a GC written in Java is
>>>type-safe?
>>>
>>>
>>>
>>>
>>Yes. We put a lot of work into making MMTk type safe. Type safety is
>>key. Perry Cheng was the person who initially did all the hard work on
>>this.
>>
>>We have introduced new magic types for Address (think void*), Word
>>(think "32 or 64 bit unsigned values"), ObjectReference (abstract notion
>>of a refernce to an object, could in principle be a handle, for Jikes
>>RVM it is an Address), etc etc. Each of these looks like a heavyweight
>>regular Java type, but our compiler "knows" about them and folds them
>>into primitives. The fact that we *do* preserve type safety is what
>>allows the opt compiler to be as agressive as it is in compiling across
>>barriers and allocations. I've provided pointers to this previously.
>>Jnode has been using these magic types for a while now (for the same
>>reasons).
>>
>>http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
>>
>>I would like (not now, I need to run) to discuss different notions of
>>modularity and modular design. We have approached it very differently
>>to you and I think it would be profitable for us all to share our thoughts.
>>
>>Cheers,
>>
>>--Steve
>>
>>
>>
[dev-tools] was Re: Against using Java to implement Java (Was: Java)
Posted by Mark Brooks <jm...@hotmail.com>.
>If we are going to entertain writing most of the JVM in a type-safe
>language, we should also consider the proposed ECMA C++/CLI. From
>what I understand, it standardizes a form of type-safe C++. It has
>the promise of keeping both the Java and C camps happy.
Not really. First, it is a Microsoft thing, tied in with .NET. Second, we
don't want to have to depend on a .NET runtime to get a Java runtime.
Third, never try to implement a large and complex existing project in a
brand new technology.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Against using Java to implement Java (Was: Java)
Posted by Weldon Washburn <we...@gmail.com>.
Steve,
Very interesting. Please point me to the web pages that show
SpecJAppServer/JBB/JVM... numbers for Jikes.
I see some mention of "magic types". Does this work around the java
verifier by coercing a reference pointer into a Java int and
vice-versa? This could be done by calling a non-verifiable chunk of
code written in Java. Something like "Object int2ref(int x);" and
"int ref2obj(Object z)". The net result sort of "C++-izes" java
without having to modify the language.
If we are going to entertain writing most of the JVM in a type-safe
language, we should also consider the proposed ECMA C++/CLI. From
what I understand, it standardizes a form of type-safe C++. It has
the promise of keeping both the Java and C camps happy.
Regarding the inlining of assembly in the JIT. You point out that
this code can be written in Java then fed to the JIT. Do you see any
reason why this code can not be written in C/C++, C#, etc?
On 5/18/05, Steve Blackburn <St...@anu.edu.au> wrote:
> Hi Weldon,
>
> It seems we have similar experiences with modularity, you in ORP, me in
> Jikes RVM and MMTk.
>
> >Elaborating on a previous comment about inlining allocation/write
> >barrier sequences. First design step: the GC team hand optimizes an
> >assembly sequence while making sure the functionality is absolutely
> >correct. Second step: the JIT team blindly inlines the GC team's
> >assembly code and starts doing performance analysis. Third step: the
> >JIT team integrates the inline sequence(s) into the IR so that all the
> >optimizations can be performed. Perhaps these steps are the same for
> >both a JVM written in Java as well as C/C++.
> >
> >
> No. It is as I stated in the post to which you were responding. In
> MMTk, we express the barriers and allocation sequences in Java and then
> the opt compiler inlines them and optimizes them. The first Jikes RVM
> collectors used assembler for the barriers, but we transitioned to
> expressing them in Java a long time ago. This gives us much greater
> expressibility on the GC side of the fence, greater portability (MMTk is
> totally architecture neutral), and better performance because it
> presents better opportunities for optimization to the compiler (constant
> folding etc etc).
>
> >I am curious if a JVM written in Java must break type-safety. Does
> >anyone know? For example, the "new" bytecode will need to manipulate
> >(gasp!) raw "C" pointers. In specific, Java code will need to
> >scribble on free memory to slice off "X" untyped bytes and return a
> >raw pointer to the base of chunk of memory. Then the java code will
> >need to use the raw pointer to install stuff like a vtable pointer.
> >Once the object is setup, the Java code can revert to running code
> >that can actually be verified. Also does anyone know the current
> >state of research on formally proving a GC written in Java is
> >type-safe?
> >
> >
> Yes. We put a lot of work into making MMTk type safe. Type safety is
> key. Perry Cheng was the person who initially did all the hard work on
> this.
>
> We have introduced new magic types for Address (think void*), Word
> (think "32 or 64 bit unsigned values"), ObjectReference (abstract notion
> of a refernce to an object, could in principle be a handle, for Jikes
> RVM it is an Address), etc etc. Each of these looks like a heavyweight
> regular Java type, but our compiler "knows" about them and folds them
> into primitives. The fact that we *do* preserve type safety is what
> allows the opt compiler to be as agressive as it is in compiling across
> barriers and allocations. I've provided pointers to this previously.
> Jnode has been using these magic types for a while now (for the same
> reasons).
>
> http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
>
> I would like (not now, I need to run) to discuss different notions of
> modularity and modular design. We have approached it very differently
> to you and I think it would be profitable for us all to share our thoughts.
>
> Cheers,
>
> --Steve
>
Re: Against using Java to implement Java (Was: Java)
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Weldon,
It seems we have similar experiences with modularity, you in ORP, me in
Jikes RVM and MMTk.
>Elaborating on a previous comment about inlining allocation/write
>barrier sequences. First design step: the GC team hand optimizes an
>assembly sequence while making sure the functionality is absolutely
>correct. Second step: the JIT team blindly inlines the GC team's
>assembly code and starts doing performance analysis. Third step: the
>JIT team integrates the inline sequence(s) into the IR so that all the
>optimizations can be performed. Perhaps these steps are the same for
>both a JVM written in Java as well as C/C++.
>
>
No. It is as I stated in the post to which you were responding. In
MMTk, we express the barriers and allocation sequences in Java and then
the opt compiler inlines them and optimizes them. The first Jikes RVM
collectors used assembler for the barriers, but we transitioned to
expressing them in Java a long time ago. This gives us much greater
expressibility on the GC side of the fence, greater portability (MMTk is
totally architecture neutral), and better performance because it
presents better opportunities for optimization to the compiler (constant
folding etc etc).
>I am curious if a JVM written in Java must break type-safety. Does
>anyone know? For example, the "new" bytecode will need to manipulate
>(gasp!) raw "C" pointers. In specific, Java code will need to
>scribble on free memory to slice off "X" untyped bytes and return a
>raw pointer to the base of chunk of memory. Then the java code will
>need to use the raw pointer to install stuff like a vtable pointer.
>Once the object is setup, the Java code can revert to running code
>that can actually be verified. Also does anyone know the current
>state of research on formally proving a GC written in Java is
>type-safe?
>
>
Yes. We put a lot of work into making MMTk type safe. Type safety is
key. Perry Cheng was the person who initially did all the hard work on
this.
We have introduced new magic types for Address (think void*), Word
(think "32 or 64 bit unsigned values"), ObjectReference (abstract notion
of a refernce to an object, could in principle be a handle, for Jikes
RVM it is an Address), etc etc. Each of these looks like a heavyweight
regular Java type, but our compiler "knows" about them and folds them
into primitives. The fact that we *do* preserve type safety is what
allows the opt compiler to be as agressive as it is in compiling across
barriers and allocations. I've provided pointers to this previously.
Jnode has been using these magic types for a while now (for the same
reasons).
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
I would like (not now, I need to run) to discuss different notions of
modularity and modular design. We have approached it very differently
to you and I think it would be profitable for us all to share our thoughts.
Cheers,
--Steve
Re: Against using Java to implement Java (Was: Java)
Posted by Weldon Washburn <we...@gmail.com>.
On 5/18/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On May 18, 2005, at 9:36 AM, Steve Blackburn wrote:
>
> > This subject has been covered in detail at least twice already.
> >
> > There is no need for any function call on the fast path of the
> > allocation sequence. In a Java in Java VM the allocation sequence
> > is inlined into the user code. This has considerable advantages
> > over "a few lines of assembler". Aside from the obvious advantage
> > of not having to express your allocator in assembler, using Java
> > also compiles to better code since the code can be optimized in
> > context (register allocation, constant folding etc), producing much
> > better code than hand crafted assembler.
> >
> > However this is small fry compared to the importance of compiling
> > write barriers correctly (barriers are used by most high
> > performance GCs and are executed far more frequently than
> > allocations). The same argument applies though. The barrier
> > expressed in Java is inlined insitu, and the optimizing compiler is
> > able to optimize in context.
> >
> > Modularization does not imply any of this.
>
> I assume you mean that Modularization is orthogonal to this - that
> they are independent aspects?
Modularization always interacts with performance. I believe empirical
evidence suggests that the performance impact of splitting out the JIT
and GC as separate modules is in the noise. I suspect the internal
JVM support for java.lang.Thread, java.lang.Object can also be split
off as a separate module with very little performance impact. It
might even be possible to include java.util.concurrent support in the
same threads module.
Elaborating on a previous comment about inlining allocation/write
barrier sequences. First design step: the GC team hand optimizes an
assembly sequence while making sure the functionality is absolutely
correct. Second step: the JIT team blindly inlines the GC team's
assembly code and starts doing performance analysis. Third step: the
JIT team integrates the inline sequence(s) into the IR so that all the
optimizations can be performed. Perhaps these steps are the same for
both a JVM written in Java as well as C/C++.
I am curious if a JVM written in Java must break type-safety. Does
anyone know? For example, the "new" bytecode will need to manipulate
(gasp!) raw "C" pointers. In specific, Java code will need to
scribble on free memory to slice off "X" untyped bytes and return a
raw pointer to the base of chunk of memory. Then the java code will
need to use the raw pointer to install stuff like a vtable pointer.
Once the object is setup, the Java code can revert to running code
that can actually be verified. Also does anyone know the current
state of research on formally proving a GC written in Java is
type-safe?
>
> geir
>
> >
> > --Steve
> >
> >
> > Weldon Washburn wrote:
> >
> >
> >> On 5/18/05, David Griffiths <da...@gmail.com> wrote:
> >>
> >>
> >>> I think it's too slow to have the overhead of a function call for
> >>> every object allocation. This is the cost of modularization. I doubt
> >>> any of the mainstream JVMs you are competing with do this.
> >>>
> >>>
> >> Yes. I agree. A clean interface would have a function call for
> >> every
> >> object allocation. However if the allocation code itself is only a
> >> few lines of assemby, it can be inlined by the JIT. Using a moving
> >> GC, it is possible to get the allocation sequence down to a bump the
> >> pointer and a compare to see if you have run off the end of the
> >> allocation area.
> >>
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 18, 2005, at 9:36 AM, Steve Blackburn wrote:
> This subject has been covered in detail at least twice already.
>
> There is no need for any function call on the fast path of the
> allocation sequence. In a Java in Java VM the allocation sequence
> is inlined into the user code. This has considerable advantages
> over "a few lines of assembler". Aside from the obvious advantage
> of not having to express your allocator in assembler, using Java
> also compiles to better code since the code can be optimized in
> context (register allocation, constant folding etc), producing much
> better code than hand crafted assembler.
>
> However this is small fry compared to the importance of compiling
> write barriers correctly (barriers are used by most high
> performance GCs and are executed far more frequently than
> allocations). The same argument applies though. The barrier
> expressed in Java is inlined insitu, and the optimizing compiler is
> able to optimize in context.
>
> Modularization does not imply any of this.
I assume you mean that Modularization is orthogonal to this - that
they are independent aspects?
geir
>
> --Steve
>
>
> Weldon Washburn wrote:
>
>
>> On 5/18/05, David Griffiths <da...@gmail.com> wrote:
>>
>>
>>> I think it's too slow to have the overhead of a function call for
>>> every object allocation. This is the cost of modularization. I doubt
>>> any of the mainstream JVMs you are competing with do this.
>>>
>>>
>> Yes. I agree. A clean interface would have a function call for
>> every
>> object allocation. However if the allocation code itself is only a
>> few lines of assemby, it can be inlined by the JIT. Using a moving
>> GC, it is possible to get the allocation sequence down to a bump the
>> pointer and a compare to see if you have run off the end of the
>> allocation area.
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Steve" == Steve Blackburn <St...@anu.edu.au> writes:
Steve> There is no need for any function call on the fast path of the
Steve> allocation sequence.
[ ... ]
Steve> However this is small fry compared to the importance of compiling
Steve> write barriers correctly (barriers are used by most high performance
Steve> GCs and are executed far more frequently than allocations).
[ ... ]
Steve> Modularization does not imply any of this.
I wanted to mention a few things on what modularity is not.
Just because we have some tunable knob, it does not imply that we must
support all possible settings of that knob. And, likewise, we are not
compelled to support every possible combination of settings of all the
knobs. Finally, modularity does not imply that all aspects of the VM
will be selectable at runtime. It is completely reasonable to require
compile-time choices.
So, in this case, it isn't as if we would have to design an allocation
interface that allows all possible choices. It can merely allow the
subset we know to be immediately usable.
Tom
Re: Against using Java to implement Java (Was: Java)
Posted by Steve Blackburn <St...@anu.edu.au>.
This subject has been covered in detail at least twice already.
There is no need for any function call on the fast path of the
allocation sequence. In a Java in Java VM the allocation sequence is
inlined into the user code. This has considerable advantages over "a
few lines of assembler". Aside from the obvious advantage of not having
to express your allocator in assembler, using Java also compiles to
better code since the code can be optimized in context (register
allocation, constant folding etc), producing much better code than hand
crafted assembler.
However this is small fry compared to the importance of compiling write
barriers correctly (barriers are used by most high performance GCs and
are executed far more frequently than allocations). The same argument
applies though. The barrier expressed in Java is inlined insitu, and
the optimizing compiler is able to optimize in context.
Modularization does not imply any of this.
--Steve
Weldon Washburn wrote:
>On 5/18/05, David Griffiths <da...@gmail.com> wrote:
>
>
>>I think it's too slow to have the overhead of a function call for
>>every object allocation. This is the cost of modularization. I doubt
>>any of the mainstream JVMs you are competing with do this.
>>
>>
>Yes. I agree. A clean interface would have a function call for every
>object allocation. However if the allocation code itself is only a
>few lines of assemby, it can be inlined by the JIT. Using a moving
>GC, it is possible to get the allocation sequence down to a bump the
>pointer and a compare to see if you have run off the end of the
>allocation area.
>
>
Re: Against using Java to implement Java (Was: Java)
Posted by Weldon Washburn <we...@gmail.com>.
On 5/18/05, David Griffiths <da...@gmail.com> wrote:
> I think it's too slow to have the overhead of a function call for
> every object allocation. This is the cost of modularization. I doubt
> any of the mainstream JVMs you are competing with do this.
Yes. I agree. A clean interface would have a function call for every
object allocation. However if the allocation code itself is only a
few lines of assemby, it can be inlined by the JIT. Using a moving
GC, it is possible to get the allocation sequence down to a bump the
pointer and a compare to see if you have run off the end of the
allocation area.
>
> Cheers,
>
> Dave
>
> On 17 May 2005 18:27:42 -0600, Tom Tromey <tr...@redhat.com> wrote:
> > >>>>> "David" == David Griffiths <da...@gmail.com> writes:
> >
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > David> written in C. One of it's API calls is to allocate a new object. How
> > David> is your JIT module going to produce code to use that API? Via a C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only. Then
> > this can be done by name. Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several). This only needs to be done once,
> > at startup.
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it. ORP already solved these problems in a
> > fairly reasonable way.
> >
> > Tom
> >
>
Re: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
David Griffiths wrote:
> By having the JIT produce code to inline the object allocation using
> its knowledge of the GC internals. I'm not recommending this approach,
> just saying that this is how things tend to be done in practice. And
> if you want to compete on speed then you're going to have to address
> the issue. (This seems to be an area where Java in Java wins if I
> understand it right, ie you can have your modularity cake and eat it
> too).
Well, inlining stuff sometimes makes things faster (though it sometimes
doesn't). But I'd be seriously surprised if object allocation was simple
enough to make it worthwhile.
I do take the point, however, that using dispatch tables without
embellishment does preclude inlining.
It doesn't take me a huge leap to imagine including a function in the
dispatch table that would do inlining instead of finding the appropriate
function, though.
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: Against using Java to implement Java (Was: Java)
Posted by David Griffiths <da...@gmail.com>.
By having the JIT produce code to inline the object allocation using
its knowledge of the GC internals. I'm not recommending this approach,
just saying that this is how things tend to be done in practice. And
if you want to compete on speed then you're going to have to address
the issue. (This seems to be an area where Java in Java wins if I
understand it right, ie you can have your modularity cake and eat it
too).
Cheers,
Dave
On 5/18/05, Ben Laurie <be...@algroup.co.uk> wrote:
> David Griffiths wrote:
> > I think it's too slow to have the overhead of a function call for
> > every object allocation. This is the cost of modularization. I doubt
> > any of the mainstream JVMs you are competing with do this.
>
> How do you propose to allocate objects without function calls?
>
> --
> 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: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
David Griffiths wrote:
> I think it's too slow to have the overhead of a function call for
> every object allocation. This is the cost of modularization. I doubt
> any of the mainstream JVMs you are competing with do this.
How do you propose to allocate objects without function calls?
--
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: Against using Java to implement Java (Was: Java)
Posted by David Griffiths <da...@gmail.com>.
I think it's too slow to have the overhead of a function call for
every object allocation. This is the cost of modularization. I doubt
any of the mainstream JVMs you are competing with do this.
Cheers,
Dave
On 17 May 2005 18:27:42 -0600, Tom Tromey <tr...@redhat.com> wrote:
> >>>>> "David" == David Griffiths <da...@gmail.com> writes:
>
> David> Maybe a concrete example would help. Let's say you have a GC module
> David> written in C. One of it's API calls is to allocate a new object. How
> David> is your JIT module going to produce code to use that API? Via a C
> David> function pointer?
>
> Yes.
>
> One way is to mandate link- or compile-time pluggability only. Then
> this can be done by name. Your JIT just references
> '&harmony_allocate_object' in its source and uses this pointer
> in the code it generates.
>
> The other way is to have the JIT call some central function to get a
> pointer to the allocator function (or functions, in libgcj it turned
> out to be useful to have several). This only needs to be done once,
> at startup.
>
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it. ORP already solved these problems in a
> fairly reasonable way.
>
> Tom
>
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Or post to the dev list first so everyone can see it, and then take a
summary to the wiki.
On May 18, 2005, at 2:43 PM, Davanum Srinivas wrote:
> Weldon,
>
> One way to handle this is to write something up on the wiki
> (http://wiki.apache.org/harmony/) and ask people to comment and then
> incorporate the comments back. So that we have a record of the
> discussion and the conclusions. Yes, we need to stick to harmony-dev
> for now.
>
> Thanks,
> dims
>
> On 5/18/05, Weldon Washburn <we...@gmail.com> wrote:
>
>> On 17 May 2005 18:27:42 -0600, Tom Tromey <tr...@redhat.com> wrote:
>>
>>>>>>>> "David" == David Griffiths <da...@gmail.com> writes:
>>>>>>>>
>>>
>>> David> Maybe a concrete example would help. Let's say you have a
>>> GC module
>>> David> written in C. One of it's API calls is to allocate a new
>>> object. How
>>> David> is your JIT module going to produce code to use that API?
>>> Via a C
>>> David> function pointer?
>>>
>>> Yes.
>>>
>>> One way is to mandate link- or compile-time pluggability only. Then
>>> this can be done by name. Your JIT just references
>>> '&harmony_allocate_object' in its source and uses this pointer
>>> in the code it generates.
>>>
>>> The other way is to have the JIT call some central function to get a
>>> pointer to the allocator function (or functions, in libgcj it turned
>>> out to be useful to have several). This only needs to be done once,
>>> at startup.
>>>
>>> For folks interested in pluggability, I advise downloading a copy of
>>> ORP and reading through it. ORP already solved these problems in a
>>> fairly reasonable way.
>>>
>>
>> Thanks. I am more than willing to respond to questions about ORP.
>> Since ORP was last posted to open source, I have done some additional
>> thinking about interfaces as well as JVM and .NET design in general.
>> I really look forward to discussing these ideas. It would be
>> great if
>> we can quickly get to the point where we can discuss interface
>> details. For example, I would like to start a detailed discussion on
>> JIT and GC interface header files. Should we start this on the
>> general harmony-dev list?
>> Weldon
>>
>>
>>>
>>> Tom
>>>
>>>
>>
>>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Davanum Srinivas <da...@gmail.com>.
Weldon,
One way to handle this is to write something up on the wiki
(http://wiki.apache.org/harmony/) and ask people to comment and then
incorporate the comments back. So that we have a record of the
discussion and the conclusions. Yes, we need to stick to harmony-dev
for now.
Thanks,
dims
On 5/18/05, Weldon Washburn <we...@gmail.com> wrote:
> On 17 May 2005 18:27:42 -0600, Tom Tromey <tr...@redhat.com> wrote:
> > >>>>> "David" == David Griffiths <da...@gmail.com> writes:
> >
> > David> Maybe a concrete example would help. Let's say you have a GC module
> > David> written in C. One of it's API calls is to allocate a new object. How
> > David> is your JIT module going to produce code to use that API? Via a C
> > David> function pointer?
> >
> > Yes.
> >
> > One way is to mandate link- or compile-time pluggability only. Then
> > this can be done by name. Your JIT just references
> > '&harmony_allocate_object' in its source and uses this pointer
> > in the code it generates.
> >
> > The other way is to have the JIT call some central function to get a
> > pointer to the allocator function (or functions, in libgcj it turned
> > out to be useful to have several). This only needs to be done once,
> > at startup.
> >
> > For folks interested in pluggability, I advise downloading a copy of
> > ORP and reading through it. ORP already solved these problems in a
> > fairly reasonable way.
>
> Thanks. I am more than willing to respond to questions about ORP.
> Since ORP was last posted to open source, I have done some additional
> thinking about interfaces as well as JVM and .NET design in general.
> I really look forward to discussing these ideas. It would be great if
> we can quickly get to the point where we can discuss interface
> details. For example, I would like to start a detailed discussion on
> JIT and GC interface header files. Should we start this on the
> general harmony-dev list?
> Weldon
>
> >
> > Tom
> >
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 18, 2005, at 1:24 PM, Weldon Washburn wrote:
>
> Thanks. I am more than willing to respond to questions about ORP.
> Since ORP was last posted to open source, I have done some additional
> thinking about interfaces as well as JVM and .NET design in general.
> I really look forward to discussing these ideas. It would be great if
> we can quickly get to the point where we can discuss interface
> details. For example, I would like to start a detailed discussion on
> JIT and GC interface header files. Should we start this on the
> general harmony-dev list?
You mean here? yes!
geir
> Weldon
>
>
>>
>> Tom
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Weldon Washburn <we...@gmail.com>.
On 17 May 2005 18:27:42 -0600, Tom Tromey <tr...@redhat.com> wrote:
> >>>>> "David" == David Griffiths <da...@gmail.com> writes:
>
> David> Maybe a concrete example would help. Let's say you have a GC module
> David> written in C. One of it's API calls is to allocate a new object. How
> David> is your JIT module going to produce code to use that API? Via a C
> David> function pointer?
>
> Yes.
>
> One way is to mandate link- or compile-time pluggability only. Then
> this can be done by name. Your JIT just references
> '&harmony_allocate_object' in its source and uses this pointer
> in the code it generates.
>
> The other way is to have the JIT call some central function to get a
> pointer to the allocator function (or functions, in libgcj it turned
> out to be useful to have several). This only needs to be done once,
> at startup.
>
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it. ORP already solved these problems in a
> fairly reasonable way.
Thanks. I am more than willing to respond to questions about ORP.
Since ORP was last posted to open source, I have done some additional
thinking about interfaces as well as JVM and .NET design in general.
I really look forward to discussing these ideas. It would be great if
we can quickly get to the point where we can discuss interface
details. For example, I would like to start a detailed discussion on
JIT and GC interface header files. Should we start this on the
general harmony-dev list?
Weldon
>
> Tom
>
Re: Against using Java to implement Java (Was: Java)
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "David" == David Griffiths <da...@gmail.com> writes:
David> Maybe a concrete example would help. Let's say you have a GC module
David> written in C. One of it's API calls is to allocate a new object. How
David> is your JIT module going to produce code to use that API? Via a C
David> function pointer?
Yes.
One way is to mandate link- or compile-time pluggability only. Then
this can be done by name. Your JIT just references
'&harmony_allocate_object' in its source and uses this pointer
in the code it generates.
The other way is to have the JIT call some central function to get a
pointer to the allocator function (or functions, in libgcj it turned
out to be useful to have several). This only needs to be done once,
at startup.
For folks interested in pluggability, I advise downloading a copy of
ORP and reading through it. ORP already solved these problems in a
fairly reasonable way.
Tom
Re: Against using Java to implement Java (Was: Java)
Posted by David Griffiths <da...@gmail.com>.
Maybe a concrete example would help. Let's say you have a GC module
written in C. One of it's API calls is to allocate a new object. How
is your JIT module going to produce code to use that API? Via a C
function pointer?
Dave
On 5/16/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> I'd only be happy here if the performance hit to cross "framework"
> and "module implementation" boundaries was borne by the *module*, not
> the framework, so that we can get fast implementations via
> homogeneous implementation language and let anyone who wants to use
> other languages bear the cost of marshaling across the boundary.
>
> if we aren't performant, it won't be interesting to users and
> innovators.
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 13, 2005, at 1:30 PM, Stefano Mazzocchi wrote:
> Ben Laurie wrote:
>
>> As I've said before, I'd like to see a framework that _allows_
>> most of the VM to be run in Java (or Python, or Perl, or Erlang,
>> or whatever-floats-your-boat), but doesn't require it.
>>
>
> Yes, I think this is the most sensible compromise.
>
> I would agree in making this one of our high level requirements for
> Harmony's architecture.
I'd only be happy here if the performance hit to cross "framework"
and "module implementation" boundaries was borne by the *module*, not
the framework, so that we can get fast implementations via
homogeneous implementation language and let anyone who wants to use
other languages bear the cost of marshaling across the boundary.
if we aren't performant, it won't be interesting to users and
innovators.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
> As I've said before, I'd like to see
> a framework that _allows_ most of the VM to be run in Java (or Python,
> or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
Yes, I think this is the most sensible compromise.
I would agree in making this one of our high level requirements for
Harmony's architecture.
--
Stefano.
Re: Against using Java to implement Java (Was: Java)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 13, 2005, at 3:58 AM, Ben Laurie wrote:
> Mark Brooks wrote:
>
>>> I hope you use C to write the VM for Harmony.
>>>
>> The chief objection I have to using C to write the VM is that it
>> introduces a host of common errors and delays associated with
>> using C or C++ for large products. C is an excellent language for
>> its purposes, but this isn't 1972. Java was created to resolve a
>> number of problems that arose from the ever-growing design of C++,
>> which I swear is rapidly becoming the new PL/1. We could use a
>> restricted subset of C++ I guess, but a lot of "gee-whiz" features
>> would have to be left out to assure cross-platform compatibility.
>> So why not use Java?
>>
>
> One of the reasons why not, from my POV, is because it runs so
> badly on most platforms. If you happen to use Windows, Solaris or
> Linux(? I don't, so I don't know) you may be happy developing in
> Java. Anywhere else, its a PITA.
>
> I've tried to sell C++ in the ASF many times. Even back when it
> wasn't quite so bloated as it is now it wasn't a popular idea. Far
> fewer people can write C++ than C, and hardly any of those can
> write _good_ C++.
I used to write good C++ (or so I thought :)
I'm happy dusting off C++ and using it again.
>
> So, I think we'll end up back at C. As I've said before, I'd like
> to see a framework that _allows_ most of the VM to be run in Java
> (or Python, or Perl, or Erlang, or whatever-floats-your-boat), but
> doesn't require it.
Right. And I really probably can't handle doing everything in C. It
will be like banging rocks together :)
But I think that this will be something we are led to by what gets
donated, or what we start playing with, rather than setting out the
direction before-hand
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Against using Java to implement Java (Was: Java)
Posted by Fernando Lozano <fe...@lozano.eti.br>.
Ian,
I guess the current state of GCJ, Kaffe and SableVM should be enough for
bootstraping harmony on BSD. Did you tried any of these?
[]s, Fernando Lozano
>>I suppose that for porting issues, a C-based bootstrap VM for platforms
>>that don't have an existing VM could be used, but I think that would be
>>more of a future project. For now, I suspect that the primary target
>>platforms for Harmony are those currently supported by Sun, primarily *nix
>>and Windows, although I think we should definitely expand to include OS X,
>>if that is possible.
>>
>>
>
>I disagree; my main interest in Harmony is for platforms that Sun does NOT support.
>Like all the BSD platforms.
>
>
>
Re: Research
Posted by Doug Lea <dl...@cs.oswego.edu>.
Geir Magnusson Jr. wrote:
> The academic community was one of the original groups we reached out
> to via Doug Lea and others :)
>
Thanks for the prod. I've been pretty swamped, but here are
a few comments on top of the excellent postings by Steve Blackburn:
It would be a tragedy if Harmony did not at least learn from
work on research JVMs. Just about every aspect of VMs has
been the subject of intense research by academics and industrial
research labs over the past 5-10 years; enough that a whole
conference is now devoted to such work (VEE --
http://www.veeconference.org/) in addition to lots of work
reported at various OO and systems conferences.
In particular, people interested in overall architecture
might want to look into OVM (http://www.ovmj.org/)
(Disclaimer -- I was loosely and indirectly involved in some of this).
The goal was to make a highly componentized and configurable JVM; at a
fine-grained enough level that you could even change object header
layouts and the like. The main demonstration of this was to make
a configurable real-time personality conformant to RTSJ.
While OVM is not a production JVM, it is the only JVM I know of
that has helped guide a pilotless drone airplane without crashing :-)
-Doug
Re: Research
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
The academic community was one of the original groups we reached out
to via Doug Lea and others :)
We're very interested in their participation, both as contributors
and users.
geir
On May 14, 2005, at 2:30 AM, Steve Blackburn wrote:
> A lot of the existing work on open VMs has come out of the academic
> and industrial research communities (Jikes RVM, SableVM, ORP, OVM,
> Joeq, LLVM...).
>
> I think it may be worthwhile considering both what the research
> community's needs are and what the research community can bring to the
> harmony project.
>
> . The research community needs access to a quality VM with a liberal
> license.
>
> - Performance is key to credibility. A research result that shows
> a 10% speedup over something we know to perform awfully is of
> little interest to anyone. This is a reason why Jikes RVM has
> been attractive to researchers. Consider the number of
> institutions, names and hours represented in this list:
> http://jikesrvm.sourceforge.net/info/papers.shtml. When I was
> at U. Mass we stopped what had been a huge effort to build our
> own JVM and instead put our resources into Jikes RVM because it
> had an outstanding optimizing compiler and (at the time) was
> very competitive with the best commercial VMs.
>
> - Software quality is very important. The software must be
> flexible and modular to facilitate rapid realization of new
> ideas.
>
> - Researchers don't want to be locked in by a license (some
> commercial licenses, for example). They also want a
> transparent development model where they can see what's going
> on and what is likely to happen. Above all, many researchers
> get a real buzz out of seeing their neat ideas being widely
> used, so they want a model that allows them to recontribute
> their work.
>
> . The research community can bring cutting edge technology to a VM.
>
> - The amount and variety of Java technology emerging from the
> academic research community is amazing. The biggest challenge
> is channeling those ideas back into VM infrastructures. This
> is partly a cultural issue and partly a software engineering
> issue. If the software is not readily amenable to
> contributions of radical technology, such contributions are
> unlikely to happen. If academics are not part of or don't
> understand the open community they won't be part of the culture
> of contribution.
>
> So, the academic community represents a huge intellectual resource.
> For a project with big ambitions and yet so dependent on cutting edge
> technology, harnessing some of that intellectual resource is going
> to be
> important.
>
> --Steve
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Research
Posted by Steve Blackburn <St...@anu.edu.au>.
A lot of the existing work on open VMs has come out of the academic
and industrial research communities (Jikes RVM, SableVM, ORP, OVM,
Joeq, LLVM...).
I think it may be worthwhile considering both what the research
community's needs are and what the research community can bring to the
harmony project.
. The research community needs access to a quality VM with a liberal
license.
- Performance is key to credibility. A research result that shows
a 10% speedup over something we know to perform awfully is of
little interest to anyone. This is a reason why Jikes RVM has
been attractive to researchers. Consider the number of
institutions, names and hours represented in this list:
http://jikesrvm.sourceforge.net/info/papers.shtml. When I was
at U. Mass we stopped what had been a huge effort to build our
own JVM and instead put our resources into Jikes RVM because it
had an outstanding optimizing compiler and (at the time) was
very competitive with the best commercial VMs.
- Software quality is very important. The software must be
flexible and modular to facilitate rapid realization of new
ideas.
- Researchers don't want to be locked in by a license (some
commercial licenses, for example). They also want a
transparent development model where they can see what's going
on and what is likely to happen. Above all, many researchers
get a real buzz out of seeing their neat ideas being widely
used, so they want a model that allows them to recontribute
their work.
. The research community can bring cutting edge technology to a VM.
- The amount and variety of Java technology emerging from the
academic research community is amazing. The biggest challenge
is channeling those ideas back into VM infrastructures. This
is partly a cultural issue and partly a software engineering
issue. If the software is not readily amenable to
contributions of radical technology, such contributions are
unlikely to happen. If academics are not part of or don't
understand the open community they won't be part of the culture
of contribution.
So, the academic community represents a huge intellectual resource.
For a project with big ambitions and yet so dependent on cutting edge
technology, harnessing some of that intellectual resource is going to be
important.
--Steve
Re: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
Ian Darwin wrote:
>>I suppose that for porting issues, a C-based bootstrap VM for platforms
>>that don't have an existing VM could be used, but I think that would be
>>more of a future project. For now, I suspect that the primary target
>>platforms for Harmony are those currently supported by Sun, primarily *nix
>>and Windows, although I think we should definitely expand to include OS X,
>>if that is possible.
>
>
> I disagree; my main interest in Harmony is for platforms that Sun does NOT support.
> Like all the BSD platforms.
Exactly.
--
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: Against using Java to implement Java (Was: Java)
Posted by Ian Darwin <ia...@darwinsys.com>.
> I suppose that for porting issues, a C-based bootstrap VM for platforms
> that don't have an existing VM could be used, but I think that would be
> more of a future project. For now, I suspect that the primary target
> platforms for Harmony are those currently supported by Sun, primarily *nix
> and Windows, although I think we should definitely expand to include OS X,
> if that is possible.
I disagree; my main interest in Harmony is for platforms that Sun does NOT support.
Like all the BSD platforms.
Re: Against using Java to implement Java (Was: Java)
Posted by Panagiotis Astithas <pa...@ebs.gr>.
Ben Laurie wrote:
> Mark Brooks wrote:
>
>>> One of the reasons why not, from my POV, is because it runs so badly
>>> on most platforms.
>>
>>
>>
>> I can't comment on that. I've used it on Solaris, Linux, and
>> Windows. However, that is a VM issue, not a language issue.
>
>
> It doesn't matter where the problem lies, the point is that I can't
> develop on the platforms I need/want to develop on.
Is it fair to assume that the problems you would be facing stem from the
unavailability of the Sun JDK for your preferred platform? In that case
if a Harmony build could be bootstrapped using gcj/kaffe/jcvm/JikesRVM
you would be a happy camper, right?
Cheers,
Panagiotis
--
Panagiotis Astithas, PhD
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: Against using Java to implement Java (Was: Java)
Posted by Mark Brooks <jm...@hotmail.com>.
>It doesn't matter where the problem lies, the point is that I can't develop
>on the platforms I need/want to develop on.
My reply wasn't intended to be dismissive. I'm short on details. What
platforms are you referring to? Even a slow base VM can be an adequate
bootstrap VM to create the initial Harmony install, and thereafter you use
Harmony.
I suppose that for porting issues, a C-based bootstrap VM for platforms that
don't have an existing VM could be used, but I think that would be more of a
future project. For now, I suspect that the primary target platforms for
Harmony are those currently supported by Sun, primarily *nix and Windows,
although I think we should definitely expand to include OS X, if that is
possible.
Again, the project leads can probably say more about what the plan is there.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
Mark Brooks wrote:
>> One of the reasons why not, from my POV, is because it runs so badly
>> on most platforms.
>
>
> I can't comment on that. I've used it on Solaris, Linux, and Windows.
> However, that is a VM issue, not a language issue.
It doesn't matter where the problem lies, the point is that I can't
develop on the platforms I need/want to develop on.
--
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: Against using Java to implement Java (Was: Java)
Posted by Mark Brooks <jm...@hotmail.com>.
>One of the reasons why not, from my POV, is because it runs so badly on
>most platforms.
I can't comment on that. I've used it on Solaris, Linux, and Windows.
However, that is a VM issue, not a language issue.
>I've tried to sell C++ in the ASF many times. Even back when it wasn't
>quite so bloated as it is now it wasn't a popular idea. Far fewer people
>can write C++ than C, and hardly any of those can write _good_ C++.
Agreed.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Against using Java to implement Java (Was: Java)
Posted by Ben Laurie <be...@algroup.co.uk>.
Mark Brooks wrote:
>> I hope you use C to write the VM for Harmony.
>
>
> The chief objection I have to using C to write the VM is that it
> introduces a host of common errors and delays associated with using C or
> C++ for large products. C is an excellent language for its purposes,
> but this isn't 1972. Java was created to resolve a number of problems
> that arose from the ever-growing design of C++, which I swear is rapidly
> becoming the new PL/1. We could use a restricted subset of C++ I guess,
> but a lot of "gee-whiz" features would have to be left out to assure
> cross-platform compatibility. So why not use Java?
One of the reasons why not, from my POV, is because it runs so badly on
most platforms. If you happen to use Windows, Solaris or Linux(? I
don't, so I don't know) you may be happy developing in Java. Anywhere
else, its a PITA.
I've tried to sell C++ in the ASF many times. Even back when it wasn't
quite so bloated as it is now it wasn't a popular idea. Far fewer people
can write C++ than C, and hardly any of those can write _good_ C++.
So, I think we'll end up back at C. As I've said before, I'd like to see
a framework that _allows_ most of the VM to be run in Java (or Python,
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
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: Against using Java to implement Java (Was: Java)
Posted by Mark Brooks <jm...@hotmail.com>.
>I hope you use C to write the VM for Harmony.
The chief objection I have to using C to write the VM is that it introduces
a host of common errors and delays associated with using C or C++ for large
products. C is an excellent language for its purposes, but this isn't 1972.
Java was created to resolve a number of problems that arose from the
ever-growing design of C++, which I swear is rapidly becoming the new PL/1.
We could use a restricted subset of C++ I guess, but a lot of "gee-whiz"
features would have to be left out to assure cross-platform compatibility.
So why not use Java?
>The reason is, that I think, that the best is, if Harmony is nearly 100%
>compatible to Suns Java.
That won't be determined by what language the VM is written in.
>If you write the VM in Java itself, then there existing some problems:
>1. you need a native-code compiler (like gcj) to create it. And if Harmony
>itself is a native-code compiler it is not 100% compatible to Suns JVM.
I'm not sure why you believe this. I think some people are confused about
this. Initial builds will have to be bootstrapped on another VM until the
build-environment becomes self-hosting, at which point, it will not be
necessary to use another VM.
This is the case with PyPy, SBCL, and many other bytecode-intepreted
self-hosting implementations of a language platform in the language itself.
My response to your other comments is in the same vein. C itself is a high
level language (it isn't assembler or machine code). The GCC compiler and
glibc are written in C. How do you think this came to be? What about that
chicken and its egg? Really, it is simple. Until the build environment
became self-hosting, it was written using another tool; once it became
self-hosting, it could be expanded and extended on itself.
That being said, I think we are all whispering in the wind here. I'm
prepared to work in C or C++ if that's what we are using. Ultimately, a
toolset is just a toolset, and that includes the language or languages used.
Not all languages are equal however; we need to think outside the box a
little if we are intent on increasing the chances of success. What is our
problem domain here? If the JLS and JVMS, together with the TCK, are our
requirements documents, then we could use almost any toolset, and the issue
becomes one of reliability and maintainability.
I assume that there is a project lead or leads associated with this coming
from the Apache project, and they will make the determination of these
initial matters.
So speak up project lead(s). We are here. We are talking a lot, but not
much is happening. Order us about. Assign work. Let's get our hands
dirty. The likelihood is that there will be changes along the way anyhow.
There almost always are, and developers dedicated to the project will simply
have to adapt.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/