It does not
however, since it is about 100 times less work to maintain vcproj and sln
files opposed to makefiles (at least in my oppinion) it just comes with
build files for the commercially most used compiler in the world.
Anyway, anyone with knowledge about ant or makefiles could get the
Stefano Mazzocchi wrote:
People, as you probably already understand, being focused on web stuff,
Apache attracted pools of people (ourselves mentors included) that know
very very little about compilers and VMs.
Speak for yourself - I've written compilers and VMs, though not for Java
and quite
The Jikes RVM experience is kind of interesting...
From the outset, one of the key goals of the project was to achieve
much greater levels of scalability than the commercial VMs could deliver
(BTW, the project was then known as Jalapeno). The design decision
was to use a multiplexed
El dom, 22-05-2005 a las 21:09 +1000, Steve Blackburn escribi:
Incidentally, this is a good example of where James Gosling misses
the
point a little: MITRE got involved in Jikes RVM not because it is
better than the Sun VM, but because it was OSS which meant they
could
fix a limitation
No matter whether you think you are starting with a JVM written in
Java or a micro-kernel-ish one in C (which seem to be the leading
options), you will probably discover that you end up writing most of
it in Java. For just about every major subsystem, you will find that
some of it has to be in
I was discussing this recently and the view was put that really
this level of scalability was probably not worth the various
sacrifices associated with the approach (our load balancing leaves
something to be desired, for example). So as far as I know, most
VMs these days just rely on
Green threads have a lot of problems that are hard to solve. You have to
deal with blocking function, interupts, syscall restarts, blocking native
code, etc...
JikesRVM handles that gracefully? My impression is that everyone is dropping
this M:N model because of implementation issues. BEA
On May 22, 2005, at 11:35 AM, Craig Blake wrote:
I was discussing this recently and the view was put that really
this level of scalability was probably not worth the various
sacrifices associated with the approach (our load balancing leaves
something to be desired, for example). So as
Hi Doug,
thanks for joining the discussion.
Doug Lea wrote:
No matter whether you think you are starting with a JVM written in
Java or a micro-kernel-ish one in C (which seem to be the leading
options), you will probably discover that you end up writing most of
it in Java.
I think that a
[Original Message]
From: Steve Blackburn [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Date: 5/20/05 2:03:30 AM
Subject: Re: [arch] VM Candidate : JikesRVM
http://jikesrvm.sourceforge.net/
... snip ...
Last Friday, I made the following proposal:
On May 22, 2005, at 12:20 PM, Dan Lydick wrote:
We don't have to eat the whole pie at once, and we don't have
to. How about the general proposal as shown here and in
recent postings of:
- FIRST: A basic JVM, written in C/C++, by some combination
of contribution, new development, and
On May 22, 2005, at 12:32 PM, Dan Lydick wrote:
What I hear in this proposal for multiple VM's is the potential for
1. munge-and-squash to create a new VM based on the
best qualities of the seeded contributions.
If we have seeded contributions. I've been proposing people look at
Seems to me that you might want to be open to either using the
platform's threading when a platform has good scalability, and punt
and do it in VM when the platform doesn't offer it.
If it can be done then I am all for it. Once the Harmony VM becomes
modular it is something that can
On May 22, 2005, at 2:59 PM, Craig Blake wrote:
Seems to me that you might want to be open to either using the
platform's threading when a platform has good scalability, and
punt and do it in VM when the platform doesn't offer it.
If it can be done then I am all for it. Once the
On May 22, 2005, at 3:17 PM, Dana P'Simer wrote:
On Fri, 2005-05-20 at 17:30 +0100, Ben Laurie wrote:
crispyalien wrote:
Hi, I am new here but I already have a stupid question ... :) ...Wil
harmony use CLASPATH project or not?
Almost certainly. Read the archives.
Hi, I am new here as
Jakob == Jakob Praher [EMAIL PROTECTED] writes:
2. Performance. The result has to be reasonable competitive
performance wise. E.g., starting eclipse has to be reasonable both in
time and space.
Jakob How are doing with gcj in this direction?
I'm not sure I understand. We do ok right now
Dan Lydick wrote:
From: [EMAIL PROTECTED]
2. There are no Java virtual machines period that are presently
practical to run high volume production code.
I meant Java virtual machines written in Java... sorry
Does anyone have any benchmarks on such designs?
As a hard-core
Thanks to the JAM post:
http://www.csc.uvic.ca/~csc586a/papers/index.html
in particular this:
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
The approach of using C Compiler generated code rather than writing a
full compiler appeals to me:
[snip]
Does anyone have any benchmarks on such designs?
As a hard-core real-time and device driver guy, I am rather
skeptical
that this is anything else but a conflict in requirements, runtime
performance in execution speed versus interpretability and/or
compilability of the runtime
[EMAIL PROTECTED] wrote:
The approach of using C Compiler generated code rather than writing a
full compiler appeals to me:
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
I am curious on how well the approach performs compared to existing JITs.
I'm admittedly biased, but the approach
Archie Cobbs wrote:
[EMAIL PROTECTED] wrote:
The approach of using C Compiler generated code rather than writing a
full compiler appeals to me:
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
I am curious on how well the approach performs compared to existing
JITs.
I'm admittedly
Hi,
One possibility I see to conciliate both is to have one of the VMs to be
considered as a bootstrap VM (so that the one that proves the fastest to
start-up is probably the obvious choice IMHO) and the other acting like a
high perf plug-in for instance. I guess there will be plenty of work
＞ No. Why would we do this?
People tend to be lazy. If they have a bundle with one VM, then they will
use that VM, for most of them, IMHO. I seriously doubt we can have people
trust an alternative VM if it is not a piece of cake (sort of "with a one
liner on the console
＞I think this discussion soon gets into a java language/system debate,
＞because one could argue why we need to do this tight bundling between
＞the bunch of classes in rt.jar and the vm version. For instance: Why do
＞I have to wait for JVM 6 to fix that bug in Swing,
Interestingly Sun Solaris 9 dropped M:N threads. From
http://www.sun.com/software/whitepapers/solaris9/multithread.pdf, One
such innovation is the move away from the original MxN model to a 1:1
implementation. Again, this is not to say that a good
implementation of the MxN model is impossible,
As I understand it there is no TCK coverage for Swing (which will
probably make that a long trip frankly) and well AWT is what AWT is. It
is unlikely that we'll achieve a satisfactory swing implementation for
some time (though there are approaches that I've seen for automating
unit tests for
26 matches
Mail list logo
