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
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 [EMAIL PROTECTED] wrote:
If we are going to entertain writing most of the JVM in a type-safe
language, we should also
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 [EMAIL PROTECTED] wrote:
David == David
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
On 5/18/05, David Griffiths [EMAIL PROTECTED] 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
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.
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 [EMAIL PROTECTED] wrote:
This subject has been covered in detail at least twice already.
There is no need for any function call on the
Steve == Steve Blackburn [EMAIL PROTECTED] 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
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
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
On 5/18/05, Geir Magnusson Jr. [EMAIL PROTECTED] 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
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
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
It may seem a very odd idea but I believe that p[arts of the VM must be
implemented at driver level to provide optimized solution for some bottlenecks
in the hosting OS besides I agree that a larger part of the VM should be
written C/C++. That's what people at Microsoft do for .NET platform.
I dont see any problem of writing the JIT in java. It looks very clearly,
and even can be developed and debugged as a normal Java application.
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.
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
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
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
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
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
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
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
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
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
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
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
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, [EMAIL PROTECTED] wrote:
On 12 May 2005, at 12:17,
Ravi,
can you please add the link to the wiki as well.
thanks,
dims
On 5/14/05, Ravi kiran Gorrepati [EMAIL PROTECTED] 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
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
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
On 5/13/05, Kev Jackson [EMAIL PROTECTED] 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
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
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
On 5/13/05, Kev Jackson [EMAIL PROTECTED] 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
35 matches
Mail list logo
