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 threadi
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 limit
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 J
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 posix
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 dropp
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 far
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 th
I think the term "battle tested for building OS and
compiler systems" puts good words to my thoughts on
why the cornerstone of Harmony should be written this
way. My earlier comment said as much, and to add in
Java-written class libraries, etc. Whatever path that
may take, starting with a C/C++
> [Original Message]
> From: Steve Blackburn <[EMAIL PROTECTED]>
> To:
> 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:
>
>
http://mail-archives.apache.org/mod_mbox/i
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 exte
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
O
These issues were being touched on a prior thread named "Class Library
Modularity".
I think this is a very interesting area. A lot of this type of
modularity stuff has been investigated in the OSGi framework for quite
some time. It is possible to go a long way toward decent modularity just
by
> [Original Message]
> From: <[EMAIL PROTECTED]>
> To:
> Date: 5/20/05 9:51:17 AM
> Subject: Re: [arch] VM Candidate : JikesRVM
http://jikesrvm.sourceforge.net/
>
> [EMAIL PROTECTED] wrote:
> > I disagree with the permise of what you are saying. Let me say "the
> > wrong thing"
> >
> > 1
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 prob
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 well. I have noticed that there seems to be a
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 Harmo
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 d
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 real
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:
http://www.csc.uvic.ca/~csc586a/papers/ertlgre
[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
[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 o
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 bi
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
(B
$B!d!!(BNo. Why would we do this?
(BPeople tend to be lazy. If they have a bundle with one VM, then they will
(Buse that VM, for most of them, IMHO. I seriously doubt we can have people
(Btrust an alternative VM if it is not a piece of cake (sort of "with a one
(Bliner on the console yo
(B
$B!d(BIf nothing else, I'd suggest this be in a FAQ somewhere so that it's
(Bclear
$B!d(Bthat "Harmony" intends to address just a small subset of the java world,
(Bnot
$B!d(Beven the one that gets the most "acrimony" in the press and on blogs.
(B
(BIncluding a good report on how wel
$B!d(BI think this discussion soon gets into a java language/system debate,
$B!d(Bbecause one could argue why we need to do this tight bundling between
$B!d(Bthe bunch of classes in rt.jar and the vm version. For instance: Why do
$B!d(BI have to wait for JVM 6 to fix that bug in Swing, whi
On May 22, 2005, at 8:23 PM, Nick Lothian wrote:
[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 interpre
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 i
> >
> > [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 interpretabi
a! we dont need any mess right up now so leave it now ;)
On 5/22/05, Ben Laurie <[EMAIL PROTECTED]> wrote:
>
> Stefano Mazzocchi wrote:
> > People, as you probably already understand, being focused on web stuff,
> > Apache attracted pools of people (ourselves mentors included) that know
> >
33 matches
Mail list logo
