You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by 王在祥 <wa...@gmail.com> on 2005/05/11 04:00:01 UTC
I hope the JVM implements most using Java itself
Hotspot is coded in C/C++, but I hope Harmony to choice Java as its major
language. there is the reasons:
1. Implement a JVM using Java is possible and effecitive enough, like the
JikesRVM, jode etc.
2. Java code has good feature for maintaince and reabability than C/C++, and
it will enable more Java fans to understand and contribute to the project.
3. a full compatible JVM implemented using Java is an exciting news for the
java world
4. Since there is already hotspot that works well, Harmony should focus
mostly on new technology and more good architecture, not the times to
complete the project.
5. A Java JVM will improve the Java/JVM technology such as GC, synchronize
and etc, to enable the JVM as fast as possible.
wangzx
Re: I hope the JVM implements most using Java itself
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Tue, 2005-05-10 at 22:53 -0600, Larry Meadors wrote:
> Despite my earlier Mono comment, I could not possibly care less what is used
> to build the JVM.
People have made a vm using Mono. See http://www.ikvm.net/
Cheers,
Mark
Re: I hope the JVM implements most using Java itself
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Dmitry,
> <constructive_interest>
[...]
> First one is of the chicken-vs-egg variety -- as the GC algorithm
> written in Java executes, won't it generate garbage of its own, and
> won't it then need to be stopped and the tiny little "real" garbage
> collector run to clean up after it? I can only see two alternatives --
> either it is going to cleanup its own garbage, which would be truly
> fantastacal... Or it will somehow not generate any garbage, which I
> think is not realistic for a Java program...
This is a very important issue.
The short answer is as follows:
a) Within the GC code itself we don't really use Java, we use
a special subset of Java and a few extensions.
b) We never call new() within the GC at runtime
c) We try not to collect ourselves ;-)
You will find the long answer buried in the source code and a somewhat
out of date paper:
http://cvs.sourceforge.net/viewcvs.py/jikesrvm/MMTk/
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/package-summary.html
http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html#mmtk-icse-2004
I'll try to give a more succinct answer here:
As for a), we essentially apply a few design patterns and idioms for
correctness and performance (more on performance later). We don't use
patterns that depend on allocating instances. In fact the only
instances we create are per-thread metadata instances which drive the
GC. These are allocated only when new threads are instantiated
(actually these are per posix thread, Jikes RVM uses an N-M threading
model).
As for b), there is not much call for dynamic memory management within a
GC. The exceptions are a) short-lived metadata such as work queues, and
b) per-object metadata such as that associated with free lists and mark
bits etc etc. We solve this by explicitly managing these special cases
from within our own framework. We have a queue mechanism that works off
raw memory and a mechanism for associating metadata with allocated
space. The details are beyond the scope of this email.
Actually c) is one of the hardest parts. It is essential that heap
objects associated with the VM and the GC are not inadvertently
collected. This requires some very careful thought (remembering that
the compiler will place our *code* into the heap too!).
As to whether this is feasible, its been done at least three times
over. First in the original Jalapeno, then in GCTk (developed while I
was at UMass) and now MMTk. Right now I am working with my students
here to push the MMTk design even cleaner while not sacrificing
performance---fun!
So, can it perform? Well it is very hard to do apples to apples
comparisons, but we measure the performance of our raw mechanisms with C
implementations as a milestone and we do very well (by this I mean we
can beat glibc's malloc for allocation performance, but this claim needs
to be covered with caveats because it is very hard to make fair
comparisons). So the raw mechanisms perform well. But then the
software engineering benefits of Java come to the fore and our capacity
to implement a toolkit and thus have a choice of many different GC
algorithms gives us a real advantage (the GC mechanism/algorithm thing
was the subject of a previous thread).
I've glossed over a huge amount of important stuff (like how we get raw
memory from the OS, how we introduce type safe pointers and object
references, etc etc).
> To summarize (and to get to the question already) - the point is that
> language shapes thought. In other words, a program designed in Java
> will naturally tend to be slower then a program designed in C, simply
> because Java most naturally expresses slower designs then C does. And
> the question is - does this agree with anyone elses experiences? And
> if it does, is it a valid argument against using Java for the design
> and implementation of the VM?
OK so there is already at least one response to this, but let me add my
experience.
I am very focused on performance. The approach Perry Cheng and I took
when writing the code for MMTk was very much that premature optimization
is indeed the root of all evil. Moreover, we placed enormous faith in
the optimizing compiler. The philosophy was to assume the optimizing
compiler was smart enough to optimize around our coding abstractions,
and then to do careful performance analysis after the fact and see where
we were being let down. In some cases the compiler was improved to deal
with our approach, other times we modified our approach.
Over time we learned certain idioms which on one hand meant we tended to
get reasonable performance first shot, but on the other may have
undermined the natural Java style we started with.
While I understand what you mean when you say: "a program designed in
Java will naturally tend to be slower then a program designed in C",
addressing that concern is one of the most important challenges of
language implementation, and is why Java performance has improved so
greatly over the past five years.
> </constructive_interest>
Cheers,
--Steve
Re: I hope the JVM implements most using Java itself
Posted by Dmitry Serebrennikov <dm...@earthlink.net>.
<constructive_interest>
I've been trying to process the idea of building java vm in java and
with the comments on this and other threads it is starting to make
sense, but I have a couple of specific question below. I would
appreciate if someone could put in a few words of explanation, perhaps
it will help others as well. Here goes...
I can see the argument for the code generator written in Java - it still
produces the same machine code, so the fact that it is written in Java
does not matter.
I can also see the argument that it is algorithms that matter, not the
language in which they are written. At least that algorithms matter more.
Ok, but here are the questions.
First one is of the chicken-vs-egg variety -- as the GC algorithm
written in Java executes, won't it generate garbage of its own, and
won't it then need to be stopped and the tiny little "real" garbage
collector run to clean up after it? I can only see two alternatives --
either it is going to cleanup its own garbage, which would be truly
fantastacal... Or it will somehow not generate any garbage, which I
think is not realistic for a Java program...
This brings me to the second question. In my experience, writing in Java
and writing in C (and therefore thinking in Java and thinking in C)
tends to produce very different programs. The languages just lead you in
different directions. "Language shapes thought," you know. So, although
one can argue that a Java program will ultimately be JITed (or WATed or
whatever) to machine code, the program itself will not be written in the
same way as a C program would be. Again, this is subjective and I expect
people will not always agree with this. But I find that when I write C
code, I'm thinking of CPU efficiency, changing strings in-place, and
using pointers. Maybe *because* C is so painful, I tend to think of the
simplest, most direct way to accomplish what is needed.
However, when writing Java, I find that I think more of correct object
abstraction for the problem at hand, code reuse, classes that maintain
consistent state. I don't think twice of using a HashMap if it happens
to be convinient, or that inheritance will cause extra indirections at
runtime.
To summarize (and to get to the question already) - the point is that
language shapes thought. In other words, a program designed in Java will
naturally tend to be slower then a program designed in C, simply because
Java most naturally expresses slower designs then C does. And the
question is - does this agree with anyone elses experiences? And if it
does, is it a valid argument against using Java for the design and
implementation of the VM?
</constructive_interest>
Regards
-dmitry
Re: I hope the JVM implements most using Java itself
Posted by Steve Blackburn <St...@anu.edu.au>.
Davanum Srinivas wrote:
>Steve,
>
>is there some writeup on the your approach to making JikesRVM "modular
>and composable"?
>
>thanks,
>dims
>
>
This is all very much work in progress, but since our thinking on this
task relates so closely to the Harmony goals, I thought it was worth
writing something down. Two important caveats:
1. I am not making any presumption that this is necessarily the
direction Jikes RVM wants to go.
2. Please note that this is *not* an official Jikes RVM
roadmap---most of this has not been openly discussed yet, and
won't happen until it is discussed first.
Goals:
o "normalizing" the Jikes RVM code base
. improved maintainability
. development with Eclipse
-> reduce impedance to contributions to the project
Context: Jikes RVM has a number of idiosyncrasies in its code base
(dependence on a pre-processor, non-standard directory
structure, weak use of packages...)
o rationalizing the build process
. improved maintainability
. use of standard tools
. support componentization
Context: Jikes RVM has a baroque build process to support
configurable builds (architectures, compilers, GC
algorithms can all be selected). The process depends on
configuration files and heafty shell scripts, rather than
orthodox build processes.
o improved componentization
. improved maintainability
. development with Eclipse
. pluggable GCs, compilers
-> strength through diversity of components
-> encourage non-trivial contributions (a new compiler)
Context: Jikes RVM has a number of key components, not all of
which are well factored.
Approach:
o identify and isolate components
a) mutually exclusive (object model, arch (IA32/PPC))
b) runtime selectable (compiler)
. structure packages so that these components map closely to the
Eclipse notion of project (self-contained modules of code)
o compile components to standalone jars
. use stubs to isolate against specifics
- For example with MMTk (Jikes RVM's memory manager), the
org.mmtk.vm subpackage implements a bunch of vm-specific stubs
which are fleshed out by any particular client VM (Jikes RVM
or jnode, for example). The mmtk.jar builds against the
stubs, but does not include them. When the VM is composed,
the appropriate org.mmtk.vm implementation is put in place.
o building/composing a system
. mostly consists of fairly simple scripts that
- define configuration-specific constants (eg BYTES_IN_WORD)
- "stitch" together some selection of the above jars
Status:
We are just about at the point of completely achieving our goals with
regards to componentizing MMTk. The final patches are being tested
right now. Applying the above approach to the rest of the VM should
not present many technical difficulties since the memory manager has
the most complex interface, but will be a *lot* of work given our
current resources. Of course an injection of new energy could
completely change this.
Re: I hope the JVM implements most using Java itself
Posted by Davanum Srinivas <da...@gmail.com>.
Steve,
is there some writeup on the your approach to making JikesRVM "modular
and composable"?
thanks,
dims
On 5/11/05, Steve Blackburn <St...@anu.edu.au> wrote:
> Hi Larry,
>
> I understand your sentiment. I am also a pragmatist.
>
> One of my major missions over the past year or so has been cleaning up
> Jikes RVM to make it more modular and composable. We've nearly got
> there with memory management, but still have a way to go with the other
> components.
>
> Why is this important?
>
> Because I want to make it easier for people to contribute to the
> project. Not just in terms of a few lines here or there, or a bell or a
> whistle, but I want people to be able to drop in alternative compilers,
> alternative GC algorithms etc. Unless the framework is right the
> impedance becomes too high and the rate of non-trivial contribution
> drops off to a trickle. Getting the framework right after the fact is
> an enormous task.
>
> The fundamental architecture of the VM is what makes or breaks it. The
> "just get it out the door" approach has its merits for some projects,
> but for something as complex as this, if you want the thing to
> last---which we do---give some thought to the architecture before you
> throw it over the fence. Choosing to build it in Java or C/C++ is a
> relatively unimportant issue for most projects, but for a JVM it will
> have a significant impact on the architecture.
>
> The goal posts are moving very fast, in terms of the spec, in terms of
> the competing technology, and in terms of the architectural targets.
> Thus the importance of ongoing non-trivial contributions is enormous
> with a project such as this.
>
> This is why I brought it up now (and that is why I prefaced my original
> comments the way I did).
>
> --Steve
>
> Larry Meadors wrote:
>
> >Despite my earlier Mono comment, I could not possibly care less what is used
> >to build the JVM. Use Ruby if it gets the job done.
> >
> >My vote would be to use whatever gets it done quickly and correctly. IMO,
> >focusing on performance at this point is important, but not critical.
> >
> >First priority: Get it out the door, and make sure it is easy to build so
> >everyone who want to tweak it can.
> >
> >Second priority: Work with the community to make it faster and more stable
> >than anything anyone has ever seen.
> >
> >
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: I hope the JVM implements most using Java itself
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Larry,
I understand your sentiment. I am also a pragmatist.
One of my major missions over the past year or so has been cleaning up
Jikes RVM to make it more modular and composable. We've nearly got
there with memory management, but still have a way to go with the other
components.
Why is this important?
Because I want to make it easier for people to contribute to the
project. Not just in terms of a few lines here or there, or a bell or a
whistle, but I want people to be able to drop in alternative compilers,
alternative GC algorithms etc. Unless the framework is right the
impedance becomes too high and the rate of non-trivial contribution
drops off to a trickle. Getting the framework right after the fact is
an enormous task.
The fundamental architecture of the VM is what makes or breaks it. The
"just get it out the door" approach has its merits for some projects,
but for something as complex as this, if you want the thing to
last---which we do---give some thought to the architecture before you
throw it over the fence. Choosing to build it in Java or C/C++ is a
relatively unimportant issue for most projects, but for a JVM it will
have a significant impact on the architecture.
The goal posts are moving very fast, in terms of the spec, in terms of
the competing technology, and in terms of the architectural targets.
Thus the importance of ongoing non-trivial contributions is enormous
with a project such as this.
This is why I brought it up now (and that is why I prefaced my original
comments the way I did).
--Steve
Larry Meadors wrote:
>Despite my earlier Mono comment, I could not possibly care less what is used
>to build the JVM. Use Ruby if it gets the job done.
>
>My vote would be to use whatever gets it done quickly and correctly. IMO,
>focusing on performance at this point is important, but not critical.
>
>First priority: Get it out the door, and make sure it is easy to build so
>everyone who want to tweak it can.
>
>Second priority: Work with the community to make it faster and more stable
>than anything anyone has ever seen.
>
>
Re: I hope the JVM implements most using Java itself
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 11, 2005, at 5:06 AM, Matthew French wrote:
>
> You do realise that there are conflicting priorities here? Get it
> right
> and do it now?
>
> As I have already stated, my priority would be to get it right. If you
> want a free Java right now, there are plenty of excellent
> candidates out
> there already.
As is mine - I think we have to be really careful to do some up-front
engineering to get this right.
[SNIP]
>
> You may get it fast enough and stable enough for 75% of users, but
> I would
> be willing to bet that many users of an open Java would have less
> mainstream uses for it, and would want the ability to tweak,
> customise, or
> maybe even gut and replace large portions of the code base.
It's got to be as fast and as stable as Sun's, IBM's or BEA's
implementation, or else our uptake won't be too high. There is no
need for slow buggy Java.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: I hope the JVM implements most using Java itself
Posted by Kristian Monsen <kr...@monsen.it>.
Matthew French wrote:
>Larry Meadors said:
>
>
>>First priority: Get it out the door, and make sure it is easy to build so
>>everyone who want to tweak it can.
>>
>>
>
>You do realise that there are conflicting priorities here? Get it right
>and do it now?
>
>
I think it is possible to do both. Some can discuss VM design, and the
ones that want some action can contribute to a project that will be
used. Classpath is a very likely candidate.
--
Kristian
Re: I hope the JVM implements most using Java itself
Posted by Matthew French <ma...@camary.co.za>.
Stefano Mazzocchi said:
> Matthew French wrote:
>> You do realise that there are conflicting priorities here? Get it right
>> and do it now?
>
> Matthew, after all these years of open source I can tell you one thing:
> there is no such thing as 'doing it right'.
Erm, yes and no.
There is the pie-in-the-sky make-it-work-the-first time definition of
'doing it right'. Anyone who has been writing code for more than a year
should know that this just doesn't happen.
The other definition of 'doing it right' would be 'trying not to do it
wrong'. Otherwise known as "look before you leap".
> This is modern software engineering and aligns very well with the
> extreme programming methodology, which has been shown to be more
> effective than traditional software engineering practices even in closed
> environments.
True enough, but even extreme programming advocates doing some design.
Sure, throw it away afterwards. But it helps to know where you are trying
to go.
One of the most valid criticisms I have seen here is that Harmony appears
to be trying to replicate many other projects. Re-inventing the
re-invention, as it were.
In my mind, I don't believe that. Because I don't want to. But it does beg
the question: what are we doing here?
Managing programmers is like trying to herd cats, now before we all go off
and do our own thing it might be helpful to draw some magic cat-repelling
lines in the sand. :)
> I used to be a hard core 'design then code' dude. Some of the people
> here know very well how painful that can be...
Yup. Fortunately I learnt from others experiences so I never did that
myself. But I have had moments when I wanted to cry - or hurt someone -
when I witness sensible people become locked in analysis paralysis.
I don't want that to happen hear. But nor do I want to stand in quicksand
thinking I am off to the beach.
>> As I have already stated, my priority would be to get it right. If you
>> want a free Java right now, there are plenty of excellent candidates out
>> there already.
>
> This seems to imply that what the others did is "wrong", or suboptimal.
Indeed I did. Although I don't want to disparage the hard work that has
gone into these projects (especially since I have not worked with any of
them long enough to know about their successes and failures), they have
all failed in one requirement - to produce a Java like system that is
widely accepted.
Which is why I would like to take a step back to understand why.
> I think this would be a mistake. In many ways, social and technological.
Mmmm. Me programmer. Foot permanently attached to mouth. :)
Seriously, one of the reasons I keep harping on about architecture is
because I see these projects as a useful part of Harmony. They all seem to
have a different focus, and therefore are scratching different itches. If
Harmony can bind these projects together, take away the tedious overhead
and provide quality assurance, then I think a lot of the work will be
done.
> Harmony is not about reinventing the wheel just because there is a clean
> slate. It's about enlarging that software ecosystem around existing
> "free and open" java solutions, hopefully building better bridges
> between the two licensing worlds as well (for sure, we already have
> better social ones!)
<snip>
> But instead of 'doing it right', I would say "draw the
> minimal possible architecture so that most can play", which is a
> community-engineering version of "do the simplest thing that can
> possibly work".
I agree on both counts.
Maybe I work in too many banks at once - but for me architecture means
defining the simplest thing that could possibly work. :)
> Hehe, it is amazing what a well behaving organic development ecosystem
> does to software. It beats, hands down, any corporate and top-bottom
> driven development. Not because volunteers are smarter (that's
> completely unrelated) but because they scratch their itches. Read:
> lazyness is a local minimization of energy.
But the question then becomes: if we are so lazy, why should we spend time
saving other people time? ;) (Yeah yeah, the issue is actually a lot more
complex than that - pride, geekiness, artisianship, the challenge, love
and care are all factors.)
My particular itch in this case is duplicated effort. I am busy scratching
it right now.
> Harmony just wants to continue that tradition and help in enlarging that
> ecosystem, friendly and for mutual benefit, hoping to capture all those
> people/interests that, for good or bad reasons, the "free software" side
> was not able to capture.
Hear, hear!
But now how do we go about doing that?
- Matthew
Re: I hope the JVM implements most using Java itself
Posted by Stefano Mazzocchi <st...@apache.org>.
Matthew French wrote:
> Larry Meadors said:
>
>>First priority: Get it out the door, and make sure it is easy to build so
>>everyone who want to tweak it can.
>
> You do realise that there are conflicting priorities here? Get it right
> and do it now?
Matthew, after all these years of open source I can tell you one thing:
there is no such thing as 'doing it right'.
The 'release early and often' concept has one incredibly big advantage
that is often overlooked: it makes the ecosystem selective, in a
darwinian sense. Try/fail cycles should be small, evolution incremental
and reversible, so that, as thermodynamics explains, the entropy of the
system doesn't increase.
This is modern software engineering and aligns very well with the
extreme programming methodology, which has been shown to be more
effective than traditional software engineering practices even in closed
environments.
I used to be a hard core 'design then code' dude. Some of the people
here know very well how painful that can be, especially when you reach
disagreement and architectures *do* look objective but at the end, they
are not, they are just an expression of personal opinions on a very
abstract level.... and disagreement becomes a religious battle.
> As I have already stated, my priority would be to get it right. If you
> want a free Java right now, there are plenty of excellent candidates out
> there already.
This seems to imply that what the others did is "wrong", or suboptimal.
I think this would be a mistake. In many ways, social and technological.
Harmony is not about reinventing the wheel just because there is a clean
slate. It's about enlarging that software ecosystem around existing
"free and open" java solutions, hopefully building better bridges
between the two licensing worlds as well (for sure, we already have
better social ones!)
> I would like to see the process being similar to a multi-threaded
> application: do a certain amount of up front work, setting out the
> boundaries and requirements. We then fire it out to the open source
> community at large and allow many, many different teams to work on
> unrelated small areas.
>
> Sound chaotic? Maybe. But so long as the boundaries are clear enough, I
> don't see much duplication of effort.
Here I agree. But instead of 'doing it right', I would say "draw the
minimal possible architecture so that most can play", which is a
community-engineering version of "do the simplest thing that can
possibly work".
>>Second priority: Work with the community to make it faster and more stable
>>than anything anyone has ever seen.
>
> I see a fundamental problem with this. I have not been on this list long,
> but already I can see there are many conflicting interests. Faster!!!
> Cross platform!!! Secure!!! Reliable!!! Free!!! Complete!!!
>
> You may get it fast enough and stable enough for 75% of users, but I would
> be willing to bet that many users of an open Java would have less
> mainstream uses for it, and would want the ability to tweak, customise, or
> maybe even gut and replace large portions of the code base.
Hehe, it is amazing what a well behaving organic development ecosystem
does to software. It beats, hands down, any corporate and top-bottom
driven development. Not because volunteers are smarter (that's
completely unrelated) but because they scratch their itches. Read:
lazyness is a local minimization of energy.
The benefit of that is the opposite: what does *NOT* itch doesn't get
scratched. Resulting in optimal use of ecosystem resources (aka 'cut the
crap and get the job done').
Collective lazyness is a less local minimizer: good architectures are
those that allow even more lazyness and less energy spent to
maintain/modify the software system.
In that regard, what the "free java" ecosystem has created is truly a
magnificent achievement: overall, even if a lot of energy was spent in
it, compared to the millions of dollars and men/years that commercial
companies poured into a JVM, it's already very efficient.
Apache shows very well what a healthy and collaborative community can do
to software development.
Harmony just wants to continue that tradition and help in enlarging that
ecosystem, friendly and for mutual benefit, hoping to capture all those
people/interests that, for good or bad reasons, the "free software" side
was not able to capture.
--
Stefano.
Re: I hope the JVM implements most using Java itself
Posted by Matthew French <ma...@camary.co.za>.
Larry Meadors said:
> First priority: Get it out the door, and make sure it is easy to build so
> everyone who want to tweak it can.
You do realise that there are conflicting priorities here? Get it right
and do it now?
As I have already stated, my priority would be to get it right. If you
want a free Java right now, there are plenty of excellent candidates out
there already.
I would like to see the process being similar to a multi-threaded
application: do a certain amount of up front work, setting out the
boundaries and requirements. We then fire it out to the open source
community at large and allow many, many different teams to work on
unrelated small areas.
Sound chaotic? Maybe. But so long as the boundaries are clear enough, I
don't see much duplication of effort.
> Second priority: Work with the community to make it faster and more stable
> than anything anyone has ever seen.
I see a fundamental problem with this. I have not been on this list long,
but already I can see there are many conflicting interests. Faster!!!
Cross platform!!! Secure!!! Reliable!!! Free!!! Complete!!!
You may get it fast enough and stable enough for 75% of users, but I would
be willing to bet that many users of an open Java would have less
mainstream uses for it, and would want the ability to tweak, customise, or
maybe even gut and replace large portions of the code base.
- Matthew
Re: I hope the JVM implements most using Java itself
Posted by Larry Meadors <la...@gmail.com>.
Despite my earlier Mono comment, I could not possibly care less what is used
to build the JVM. Use Ruby if it gets the job done.
My vote would be to use whatever gets it done quickly and correctly. IMO,
focusing on performance at this point is important, but not critical.
First priority: Get it out the door, and make sure it is easy to build so
everyone who want to tweak it can.
Second priority: Work with the community to make it faster and more stable
than anything anyone has ever seen.
Larry
On 5/10/05, 王在祥 <wa...@gmail.com> wrote:
>
> Hotspot is coded in C/C++, but I hope Harmony to choice Java as its major
> language. there is the reasons:
>
> 1. Implement a JVM using Java is possible and effecitive enough, like the
> JikesRVM, jode etc.
> 2. Java code has good feature for maintaince and reabability than C/C++,
> and
> it will enable more Java fans to understand and contribute to the project.
> 3. a full compatible JVM implemented using Java is an exciting news for
> the
> java world
> 4. Since there is already hotspot that works well, Harmony should focus
> mostly on new technology and more good architecture, not the times to
> complete the project.
> 5. A Java JVM will improve the Java/JVM technology such as GC, synchronize
> and etc, to enable the JVM as fast as possible.
>
> wangzx
>
>
Re: I hope the JVM implements most using Java itself
Posted by usman bashir <gr...@gmail.com>.
Geir I ll favor ur argument, at this time no need to worry about coding yet,
i dont understand why guys are being impatient, when u go for quality ,
performance, and efficiency then u have to think before u leap. so i think
every one of us knows these are proof of concept things which we will
implement, so we can ignore aa code for few moment. like some one proposed
it to model in some functional lang.
On 5/15/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> I read the whole thread.
>
> Given that we're all itching to write code, are there experiments we
> can start doing?
>
> geir
>
> On May 10, 2005, at 10:00 PM, 王在祥 wrote:
>
> > Hotspot is coded in C/C++, but I hope Harmony to choice Java as its
> > major
> > language. there is the reasons:
> >
> > 1. Implement a JVM using Java is possible and effecitive enough,
> > like the
> > JikesRVM, jode etc.
> > 2. Java code has good feature for maintaince and reabability than C/
> > C++, and
> > it will enable more Java fans to understand and contribute to the
> > project.
> > 3. a full compatible JVM implemented using Java is an exciting news
> > for the
> > java world
> > 4. Since there is already hotspot that works well, Harmony should
> > focus
> > mostly on new technology and more good architecture, not the times to
> > complete the project.
> > 5. A Java JVM will improve the Java/JVM technology such as GC,
> > synchronize
> > and etc, to enable the JVM as fast as possible.
> >
> > wangzx
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
--
Usman Bashir
Certified IBM XML Solution Developer
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore
Re: I hope the JVM implements most using Java itself
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I read the whole thread.
Given that we're all itching to write code, are there experiments we
can start doing?
geir
On May 10, 2005, at 10:00 PM, 王在祥 wrote:
> Hotspot is coded in C/C++, but I hope Harmony to choice Java as its
> major
> language. there is the reasons:
>
> 1. Implement a JVM using Java is possible and effecitive enough,
> like the
> JikesRVM, jode etc.
> 2. Java code has good feature for maintaince and reabability than C/
> C++, and
> it will enable more Java fans to understand and contribute to the
> project.
> 3. a full compatible JVM implemented using Java is an exciting news
> for the
> java world
> 4. Since there is already hotspot that works well, Harmony should
> focus
> mostly on new technology and more good architecture, not the times to
> complete the project.
> 5. A Java JVM will improve the Java/JVM technology such as GC,
> synchronize
> and etc, to enable the JVM as fast as possible.
>
> wangzx
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: I hope the JVM implements most using Java itself
Posted by Raffaele Castagno <ra...@gmail.com>.
2005/5/11, 王在祥 <wa...@gmail.com>:
>
> ok. the JIT output native machine code, then it is the JVM runtime to
> execute it.
>
> JVM = (Java Source) --compile-to- (byecode) -- precompile-to- (Nativecode)
>
> (User Java Code) --compile-to- (Bytecode)
>
> the JVM now load bytecode, calls the JIT to translate it native code, and
> execute the native code.
>
> So how the JVM execute the native code? it is compiled by the JIT compiler
> also, but it looks that it is something magic.
>
Hi, I'm new here...
AFAIK, this is the process:
javac = (Java Source) --compile-to-- (Bytecode)
java (no-jit) = (Bytecode [classes]) --compile-to-- (Native code)
java (jit) = (Bytecode [methods]) --compile-to- (Native code)
--when-needed--
The difference is that non-JIT VM will compile to native code an entire
class as soon as it's loaded, while JIT VM will compile to native code only
single methods when some one use them.
In both cases, at this time you will have inside the VM a piece of native
code, wich is not so different from a classic c/c++ compiled executable. It
will be loaded in memory, and executed.
best regards
Raffaele
Re: I hope the JVM implements most using Java itself
Posted by Torsten Curdt <tc...@apache.org>.
> ok. the JIT output native machine code, then it is the JVM runtime to
> execute it.
>
> JVM = (Java Source) --compile-to- (byecode) -- precompile-to- (Nativecode)
>
> (User Java Code) --compile-to- (Bytecode)
sure
> the JVM now load bytecode, calls the JIT to translate it native code, and
> execute the native code.
...and "executes the native code" from a JVM?
Sorry, cannot see how to do that.
> So how the JVM execute the native code? it is compiled by the JIT compiler
> also, but it looks that it is something magic.
Magic doesn't count ;)
cheers
--
Torsten
Re: I hope the JVM implements most using Java itself
Posted by Jonathan Worthington <jo...@jwcs.net>.
"王在祥" <wa...@gmail.com> wrote:
> ok. the JIT output native machine code, then it is the JVM runtime to
> execute it.
>
> JVM = (Java Source) --compile-to- (byecode) -- precompile-to- (Nativecode)
>
> (User Java Code) --compile-to- (Bytecode)
>
> the JVM now load bytecode, calls the JIT to translate it native code, and
> execute the native code.
>
> So how the JVM execute the native code? it is compiled by the JIT compiler
> also, but it looks that it is something magic.
>
The point of the JIT is that the JVM itself doesn't execute the native
code - as in, not in the way it executes bytecode (though interpret is the
right word for this, I guess).
To my understanding a very over-simplified outline of process to doing JIT
is:-
1) Take your JVM bytecode and step through it op by op for the bit we want
to JIT.
2) For ops that we know how to generate native code for, spit out (native)
machine code into a chunk of memory. For those you don't, put in a call to
a chunk of code in the JVM that does that op. (This also means you can
build up JIT support op by op - and some ops will probably always be to
complex to JIT - I may be wrong here though).
3) Put some magic machine code on the end of the chunk of machine code the
JIT just generated that returns control to the JVM when execution is
complete.
4) Write some code that causes the CPU to jump to the chunk of machine code
that was generated. At this point, the CPU itself is doing all of the
instruction fetch and execute, which is why with JIT you can (in theory) get
a bytecode instruction done in one CPU instruction - there is no overhead
from the JVM.
You can do further "tricks", like caching machine code that was generated
for quick execution again later, or spotting very frequently executed chunks
of machine code and deciding to try doing some optimizations on them.
Sorry if everyone knew this already, but hope it might help those less
familiar with JIT. Oh, and hi from yet another list newbie. :-)
Jonathan
Re: I hope the JVM implements most using Java itself
Posted by 王在祥 <wa...@gmail.com>.
ok. the JIT output native machine code, then it is the JVM runtime to
execute it.
JVM = (Java Source) --compile-to- (byecode) -- precompile-to- (Nativecode)
(User Java Code) --compile-to- (Bytecode)
the JVM now load bytecode, calls the JIT to translate it native code, and
execute the native code.
So how the JVM execute the native code? it is compiled by the JIT compiler
also, but it looks that it is something magic.
2005/5/11, Torsten Curdt <tc...@apache.org>:
>
>
> All ok but ...now how do you
> want to execute that from java - easily?
>
> cheers
> --
> Torsten
>
>
>
Re: I hope the JVM implements most using Java itself
Posted by Paul Gearon <ge...@ieee.org>.
On 11/05/2005, at 11:00 PM, Christian Willy Asmussen - Young Padovan
wrote:
> Paul Gearon wrote:
>> On 11/05/2005, at 4:49 PM, Torsten Curdt wrote:
>>>> maybe we can think the JIT Compiler as a simple box which input
>>>> "bytecode"
>>>> and output "machine code".
>>> ...native machine code I assume.
>>>
>>> All ok but ...now how do you
>>> want to execute that from java - easily?
>> Not saying you want to do it this way, but a question like this
>> demands an answer. :-)
> Isn't this what mono/GNUdotNet does?
No idea, but it's an obvious (and easy) approach, which is why I
described it. (well, it's obvious for me, because I've been playing
with JNI lately). The fact that someone else chose to use it is no
surprise. (This is a good example of why I hate software patents)
The reason I said that you might not want to do it this way is
because it *is* so obvious. There's probably some subtle technique
that can be applied that is non-obvious and better. But the question
asked for "easy", so that's how I responded. :-)
Regards,
Paul Gearon
Re: I hope the JVM implements most using Java itself
Posted by Christian Willy Asmussen - Young Padovan <kr...@arca.ime.usp.br>.
Paul Gearon wrote:
>
> On 11/05/2005, at 4:49 PM, Torsten Curdt wrote:
>
>>> maybe we can think the JIT Compiler as a simple box which input
>>> "bytecode"
>>> and output "machine code".
>>>
>>
>> ...native machine code I assume.
>>
>> All ok but ...now how do you
>> want to execute that from java - easily?
>
>
> Not saying you want to do it this way, but a question like this
> demands an answer. :-)
Isn't this what mono/GNUdotNet does?
Re: I hope the JVM implements most using Java itself
Posted by Paul Gearon <ge...@ieee.org>.
On 11/05/2005, at 4:49 PM, Torsten Curdt wrote:
>> maybe we can think the JIT Compiler as a simple box which input
>> "bytecode"
>> and output "machine code".
>>
>
> ...native machine code I assume.
>
> All ok but ...now how do you
> want to execute that from java - easily?
Not saying you want to do it this way, but a question like this
demands an answer. :-)
Use System.getProperty() with os.arch for the CPU type and os.name/
os.version for the OS. These tell you what type of native code to
generate. It doesn't matter what language you write it in, you need
different implementations for different OS/architectures.
Put the generated code into a byte array, or better yet, a
MappedByteBuffer. Then send the whole lot off to a native method
that calls into the pointer it's given. The native library needed to
do that could be implemented in a trivially small dll, so, dylib,
etc. If you really want to avoid using other languages, even for
this, then since you already have Java building native code, the
startup code for the JIT could write out it's own binary library
before loading it.
The hardest part about all of this, is the code that JITs bytecode
into native instructions. Not difficult, but very time consuming.
The alternatives are probably better, but this doesn't sound hard to
me. :-)
Regards,
Paul Gearon
Re: I hope the JVM implements most using Java itself
Posted by Torsten Curdt <tc...@apache.org>.
> maybe we can think the JIT Compiler as a simple box which input "bytecode"
> and output "machine code".
...native machine code I assume.
All ok but ...now how do you
want to execute that from java - easily?
cheers
--
Torsten
Re: I hope the JVM implements most using Java itself
Posted by 王在祥 <wa...@gmail.com>.
maybe we can think the JIT Compiler as a simple box which input "bytecode"
and output "machine code".
In such a case, of course we can choose the Java language to implements the
JIT itself.
Hm.... I'd consider JIT compilers pretty low-level.
>
> Do you guys really think we can integrate this
> low-level with a higher-level language easily?
>
> ...despite that it just sounds really big and
> memory consuming.
>
> I am only expressing some fears here.
> Would be glad to be proven wrong.
>
> cheers
> --
> Torsten
>
>
>
Re: I hope the JVM implements most using Java itself
Posted by Stefano Mazzocchi <st...@apache.org>.
Anthony Green wrote:
> On Wed, 2005-05-11 at 13:10 -0500, Archie Cobbs wrote:
>
>>Those are good points.. I'm not saying JIT is bad, I'm just saying
>>WAT has a place and can sometimes do things that JITs cannot because
>>of time constraints.
>
>
> Yes - in the real world, JITs don't always necessarily win.
>
> Here's an example. Wikipedia is currently using a gcj-built version of
> Lucene to power their search feature. Here's some text describing a
> benchmark that help them make this decision:
>
> ----- cut here ------------------------------------------------
> Crude, simple benchmark; does single-word fulltext search for “pope” 100
> times sequentially. This is a fairly popular word, and returns 6890
> results from the test database used (English Wikipedia, 2005-03-09
> dump). Time returned is the average time spent for a request on the
> client, over the second set of 100 runs.
>
> GCJ 4.0 -O2: 588.3437 ms (fastest)
> Sun Java 1.5 -server: 636.9209 ms
> Sun Java 1.5: 695.5374 ms
> GCJ 4.0: 707.2302 ms
> Mono 1.1.6: 894.4488 ms (slowest)
>
> Each version of the daemon read from the same index set, which I had
> generated with the Mono-based version. (dotlucene 1.4 is index-
> compatible with the Java Lucene 1.4.)
> ----- cut here ------------------------------------------------
>
> I'm fairly certain we can do much better with additional compiler
> options (-march=pentium4 and the like).
>
> In any case, this is a showcase app for Apache + FSF technology working
> together in an important real-world application.
Awesome! we should make a PR out of this!
--
Stefano.
Re: I hope the JVM implements most using Java itself
Posted by Anthony Green <gr...@redhat.com>.
On Wed, 2005-05-11 at 13:10 -0500, Archie Cobbs wrote:
> Those are good points.. I'm not saying JIT is bad, I'm just saying
> WAT has a place and can sometimes do things that JITs cannot because
> of time constraints.
Yes - in the real world, JITs don't always necessarily win.
Here's an example. Wikipedia is currently using a gcj-built version of
Lucene to power their search feature. Here's some text describing a
benchmark that help them make this decision:
----- cut here ------------------------------------------------
Crude, simple benchmark; does single-word fulltext search for “pope” 100
times sequentially. This is a fairly popular word, and returns 6890
results from the test database used (English Wikipedia, 2005-03-09
dump). Time returned is the average time spent for a request on the
client, over the second set of 100 runs.
GCJ 4.0 -O2: 588.3437 ms (fastest)
Sun Java 1.5 -server: 636.9209 ms
Sun Java 1.5: 695.5374 ms
GCJ 4.0: 707.2302 ms
Mono 1.1.6: 894.4488 ms (slowest)
Each version of the daemon read from the same index set, which I had
generated with the Mono-based version. (dotlucene 1.4 is index-
compatible with the Java Lucene 1.4.)
----- cut here ------------------------------------------------
I'm fairly certain we can do much better with additional compiler
options (-march=pentium4 and the like).
In any case, this is a showcase app for Apache + FSF technology working
together in an important real-world application.
AG
Re: I hope the JVM implements most using Java itself
Posted by Archie Cobbs <ar...@dellroad.org>.
Brian Goetz wrote:
>> This code can be agressively optimized (including inlining, array bounds
>> check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being
>> a perfect example. Not to mention the application itself. After all,
>> who only runs an application once? You can WAT compile the application
>> and then all of your code (except for anything loaded & run dynamically
>> at runtime) will run fast.
>
> This argument neglects many of the benefits of JITs. First of all, you
> can't inline virtual method calls effectively (at which point, you can
> basically forget about optimizing) unless you know every class that is
> going to be loaded, which you never do.
>
> Modern JITs can make aggressive assumptions about inlining based on
> current information and back them out if the information is later
> invalidated (say, by another class being loaded.) Such speculative
> optimizations are very effective.
>
> JITs can also make better optimization decisions based on profiling data
> gathered during interpretation. This is the JVM equivalent of branch
> prediction -- by the time the code is compiled, the JVM has a lot of
> information such as "how often is this branch taken" (which can be used
> to make inlining space-vs-speed tradeoffs) and "how often is this lock
> contended" (which can be used to make decisions about whether or not to
> even try thin-locking.) And the list goes on and on.
Those are good points.. I'm not saying JIT is bad, I'm just saying
WAT has a place and can sometimes do things that JITs cannot because
of time constraints.
Moreover, in theory any optimization a JIT could perform, a WAT could
also perform, given the same information. E.g., profiling information,
or information about which classes are expected to be loaded.
Ideally, you'd have both!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: I hope the JVM implements most using Java itself
Posted by Brian Goetz <br...@quiotix.com>.
> Imagine your execution engine (or whatever you call it) makes the
> assumption that object references are direct and don't change, for
> the naturally desirable reason that it wants to be fast. Then along
> comes somebody who says, "Hey, I want to implement a copying GC!"
> Oops, then what?
Copying is only one of many garbage collection approaches that involves
relocating objects. So does mark-compact, and most of the interesting
concurrent and parallel algorithms.
I think you mean "relocating" GC. (By the way, not all relocating GC's
today involve an extra level of indirection, so the performance hit to
the execution engine is not necessarily what you think it is.)
> This code can be agressively optimized (including inlining, array bounds
> check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being
> a perfect example. Not to mention the application itself. After all,
> who only runs an application once? You can WAT compile the application
> and then all of your code (except for anything loaded & run dynamically
> at runtime) will run fast.
This argument neglects many of the benefits of JITs. First of all, you
can't inline virtual method calls effectively (at which point, you can
basically forget about optimizing) unless you know every class that is
going to be loaded, which you never do.
Modern JITs can make aggressive assumptions about inlining based on
current information and back them out if the information is later
invalidated (say, by another class being loaded.) Such speculative
optimizations are very effective.
JITs can also make better optimization decisions based on profiling data
gathered during interpretation. This is the JVM equivalent of branch
prediction -- by the time the code is compiled, the JVM has a lot of
information such as "how often is this branch taken" (which can be used
to make inlining space-vs-speed tradeoffs) and "how often is this lock
contended" (which can be used to make decisions about whether or not to
even try thin-locking.) And the list goes on and on.
Re: I hope the JVM implements most using Java itself
Posted by Archie Cobbs <ar...@dellroad.org>.
Robin John Garner wrote:
>>Yes, and this brings up an important point: the VM should be designed
>>to allow code execution to easily transfer between compiled C/C++ code
>>and JIT'd (or whatever) Java code. This is in some sense already a
>>requirement anyway because of things like user-defined class loaders.
>
> This is a tricky issue. One of the nice things about gcj is the CNI
> interface between Java and C++ - the ability to switch seamlessly between
> Java and C++ is great when interfacing code written in both languages.
> This does however come at a cost.
>
> Firstly, the inherent safety of Java means that you can use memory
> management techniques (copying garbage collectors) with the accompanying
> performance advantages. While it is possible to do copying collection in
> a restricted subset of C/C++ if you have the necessary compiler support,
> this isn't exactly the seamless integration that is desired here.
That's a good argument against copying collectors in my opinion :-)
But this brings up a good example of what I was talking about earlier
about how a VM cannot always easily be "modularized" without penalty.
Imagine your execution engine (or whatever you call it) makes the
assumption that object references are direct and don't change, for
the naturally desirable reason that it wants to be fast. Then along
comes somebody who says, "Hey, I want to implement a copying GC!"
Oops, then what?
The alternative is to make your execution engine support BOTH direct
and copying GC's. But that sounds pretty slow (or at least pretty
complicated) to me.
> Secondly, JIT compilers have various performance advantages over their
> ahead-of-time peers, and in particular library code can be inlined into
> user applications at run time. This advantage is lost when crossing a
> language boundary (unless the C compiler can emit Java bytecode :-).
Again showing my JC bias here, but this is a weak argument IMHO. Much of the
bytecode that a VM will execute in a normal application is not actually
"application" code but core classes and libraries like Xerces, etc.
This code can be agressively optimized (including inlining, array bounds
check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being
a perfect example. Not to mention the application itself. After all,
who only runs an application once? You can WAT compile the application
and then all of your code (except for anything loaded & run dynamically
at runtime) will run fast.
Of course, there's no reason a JVM couldn't have both a JIT compiler
and a WAT code generator... then you'd get the best of both worlds.
All you'd need is to generate code that follows the same conventions.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: I hope the JVM implements most using Java itself
Posted by Robin John Garner <ro...@anu.edu.au>.
> Yes, and this brings up an important point: the VM should be designed
> to allow code execution to easily transfer between compiled C/C++ code
> and JIT'd (or whatever) Java code. This is in some sense already a
> requirement anyway because of things like user-defined class loaders.
This is a tricky issue. One of the nice things about gcj is the CNI
interface between Java and C++ - the ability to switch seamlessly between
Java and C++ is great when interfacing code written in both languages.
This does however come at a cost.
Firstly, the inherent safety of Java means that you can use memory
management techniques (copying garbage collectors) with the accompanying
performance advantages. While it is possible to do copying collection in
a restricted subset of C/C++ if you have the necessary compiler support,
this isn't exactly the seamless integration that is desired here.
Secondly, JIT compilers have various performance advantages over their
ahead-of-time peers, and in particular library code can be inlined into
user applications at run time. This advantage is lost when crossing a
language boundary (unless the C compiler can emit Java bytecode :-).
Robin
Re: I hope the JVM implements most using Java itself
Posted by Archie Cobbs <ar...@dellroad.org>.
Torsten Curdt wrote:
> Hm.... I'd consider JIT compilers pretty low-level.
>
> Do you guys really think we can integrate this
> low-level with a higher-level language easily?
Yes, and this brings up an important point: the VM should be designed
to allow code execution to easily transfer between compiled C/C++ code
and JIT'd (or whatever) Java code. This is in some sense already a
requirement anyway because of things like user-defined class loaders.
Then the API's for the various subsystems can be independent of the
language (C/C++ or Java) and therefore implementations of those API's
can be written in either language and more easily evolve over time.
E.g., in JCVM the code generator is written in Java, and is
invoked on demand from within the VM when a new class needs to
be compiled, etc.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: I hope the JVM implements most using Java itself
Posted by Torsten Curdt <tc...@apache.org>.
>> Hotspot is coded in C/C++, but I hope Harmony to choice Java as its
>> major language. there is the reasons:
>>
>> 1. Implement a JVM using Java is possible and effecitive enough, like
>> the JikesRVM, jode etc.
>> 2. Java code has good feature for maintaince and reabability than
>> C/C++, and it will enable more Java fans to understand and contribute
>> to the project.
>> 3. a full compatible JVM implemented using Java is an exciting news
>> for the java world
>> 4. Since there is already hotspot that works well, Harmony should
>> focus mostly on new technology and more good architecture, not the
>> times to complete the project.
>> 5. A Java JVM will improve the Java/JVM technology such as GC,
>> synchronize and etc, to enable the JVM as fast as possible.
Hm.... I'd consider JIT compilers pretty low-level.
Do you guys really think we can integrate this
low-level with a higher-level language easily?
...despite that it just sounds really big and
memory consuming.
I am only expressing some fears here.
Would be glad to be proven wrong.
cheers
--
Torsten
Re: I hope the JVM implements most using Java itself
Posted by tetsuo <ro...@gmail.com>.
On 5/11/05, Robin Garner <Ro...@anu.edu.au> wrote:
> You might like to take a look at how the org.vmmagic classes implemented
> in JikesRVM and (I believe) in JNode do this. Essentially you this
> interface defines 'magic' classes such as 'Address' that can be used in
> the VM internals to access raw memory. As far as the program text goes,
> you are calling a method of an object, but the compiler produced
> optimized machine code to do memory loads, stores etc. So you get the
> power to do low-level things, but with some measure of type safety etc.
So, you want to create your own modified (proprietary, incompatible)
Java (J++?) to write the 'real' Java implementation? :\
I think it would be more feasible to pick the most near-complete
ASL-compatible pieces already coded out there (kaffe, classpath), help
them to achieve completeness, and integrate all of them in a complete
package, just like Geronimo did. Of course they should satisfy some
requirements, and it may require changes, but it's just like JOTM did
to satisfy Geronimo's requirements
(http://www.theserverside.com/talks/videos/MichaelGiroux/interview.tss?bandwidth=dsl).
Re: I hope the JVM implements most using Java itself
Posted by Torsten Curdt <tc...@apache.org>.
>> Huh!? Sounds really interesting!
>>
>> ...be sure I'll have a look - thanks for the pointer
>
> Pointer to raw memory - now that's funny!
LOL
--
Torsten
Re: I hope the JVM implements most using Java itself
Posted by bwobbones <bw...@gmail.com>.
Pointer to raw memory - now that's funny!
Torsten Curdt wrote:
>>You might like to take a look at how the org.vmmagic classes implemented
>>in JikesRVM and (I believe) in JNode do this. Essentially you this
>>interface defines 'magic' classes such as 'Address' that can be used in
>>the VM internals to access raw memory.
>>
>>
>
>Huh!? Sounds really interesting!
>
>...be sure I'll have a look - thanks for the pointer
>
>cheers
>--
>Torsten
>
>
Re: I hope the JVM implements most using Java itself
Posted by Torsten Curdt <tc...@apache.org>.
> You might like to take a look at how the org.vmmagic classes implemented
> in JikesRVM and (I believe) in JNode do this. Essentially you this
> interface defines 'magic' classes such as 'Address' that can be used in
> the VM internals to access raw memory.
Huh!? Sounds really interesting!
...be sure I'll have a look - thanks for the pointer
cheers
--
Torsten
Re: I hope the JVM implements most using Java itself
Posted by Robin Garner <Ro...@anu.edu.au>.
You might like to take a look at how the org.vmmagic classes implemented
in JikesRVM and (I believe) in JNode do this. Essentially you this
interface defines 'magic' classes such as 'Address' that can be used in
the VM internals to access raw memory. As far as the program text goes,
you are calling a method of an object, but the compiler produced
optimized machine code to do memory loads, stores etc. So you get the
power to do low-level things, but with some measure of type safety etc.
One of the key advantages of implementing the VM in Java is that
performance critical code fragments, such as the memory allocator, can
be inlined right through into the user code, with no special effort on
the part of the compiler.
Robin
On Wed, 2005-05-11 at 00:26 -0700, Will Pugh wrote:
> For most applications I would agree. GC is a pretty good way to go, it
> has a number of good properties such as fast allocation, pretty decent
> object grouping in many cases, pretty fast, etc.
>
> However, you still can't work with raw memory, e.g. allocating blocks of
> memory for working with many of the same objects, moving objects around
> in physical memory, physically changing vtables for exisiting Java
> Objects (potentially useful for some optimizations). A JVM has more to
> do than just turn bytecode into native code, it also needs to manage
> memory, changing already JITed machine code, potentially changing
> existing object layouts/vtables.
>
>
> --Will
>
> 王在祥 wrote:
>
> >Sure. So I think the new JVM should provide more good memory control than
> >Hotspot. I think the escape analysis would help this.
> >
> >So:
> >1. allocate object is mostly as quick as stack object.
> >2. most object will be gabage and throw away as quickly and takes no more GC
> >cost.
> >
> >In this case, we may inprove the memory control and makes the JVM more
> >effective on GC.
> >
> >:) it looks the Hotspot team dont believe escape analysis would help GC on
> >the forums.java.net <http://forums.java.net> discussion.
> >
> >2005/5/11, Will Pugh <wi...@sourcelabs.com>:
> >
> >
> >>I think you would also want to pay attention to how much control you
> >>need over memory allocation. Java doesn't give you much control over
> >>memory, yet in many scenarios (such as start-up time or running on
> >>devices) working set can be just as important as the actual codes
> >>executed for performance. You would have much more control over working
> >>set/memory if you used C/C++.
Re: I hope the JVM implements most using Java itself
Posted by 王在祥 <wa...@gmail.com>.
The Jikes RVM already dones this well.
2005/5/11, Will Pugh <wi...@sourcelabs.com>:
>
> For most applications I would agree. GC is a pretty good way to go, it
> has a number of good properties such as fast allocation, pretty decent
> object grouping in many cases, pretty fast, etc.
>
>
>
Re: I hope the JVM implements most using Java itself
Posted by Will Pugh <wi...@sourcelabs.com>.
For most applications I would agree. GC is a pretty good way to go, it
has a number of good properties such as fast allocation, pretty decent
object grouping in many cases, pretty fast, etc.
However, you still can't work with raw memory, e.g. allocating blocks of
memory for working with many of the same objects, moving objects around
in physical memory, physically changing vtables for exisiting Java
Objects (potentially useful for some optimizations). A JVM has more to
do than just turn bytecode into native code, it also needs to manage
memory, changing already JITed machine code, potentially changing
existing object layouts/vtables.
--Will
王在祥 wrote:
>Sure. So I think the new JVM should provide more good memory control than
>Hotspot. I think the escape analysis would help this.
>
>So:
>1. allocate object is mostly as quick as stack object.
>2. most object will be gabage and throw away as quickly and takes no more GC
>cost.
>
>In this case, we may inprove the memory control and makes the JVM more
>effective on GC.
>
>:) it looks the Hotspot team dont believe escape analysis would help GC on
>the forums.java.net <http://forums.java.net> discussion.
>
>2005/5/11, Will Pugh <wi...@sourcelabs.com>:
>
>
>>I think you would also want to pay attention to how much control you
>>need over memory allocation. Java doesn't give you much control over
>>memory, yet in many scenarios (such as start-up time or running on
>>devices) working set can be just as important as the actual codes
>>executed for performance. You would have much more control over working
>>set/memory if you used C/C++.
>>
>>
>>
>>
>>
>
>
>
Re: I hope the JVM implements most using Java itself
Posted by 王在祥 <wa...@gmail.com>.
Sure. So I think the new JVM should provide more good memory control than
Hotspot. I think the escape analysis would help this.
So:
1. allocate object is mostly as quick as stack object.
2. most object will be gabage and throw away as quickly and takes no more GC
cost.
In this case, we may inprove the memory control and makes the JVM more
effective on GC.
:) it looks the Hotspot team dont believe escape analysis would help GC on
the forums.java.net <http://forums.java.net> discussion.
2005/5/11, Will Pugh <wi...@sourcelabs.com>:
>
> I think you would also want to pay attention to how much control you
> need over memory allocation. Java doesn't give you much control over
> memory, yet in many scenarios (such as start-up time or running on
> devices) working set can be just as important as the actual codes
> executed for performance. You would have much more control over working
> set/memory if you used C/C++.
>
>
>
Re: I hope the JVM implements most using Java itself
Posted by Will Pugh <wi...@sourcelabs.com>.
I think you would also want to pay attention to how much control you
need over memory allocation. Java doesn't give you much control over
memory, yet in many scenarios (such as start-up time or running on
devices) working set can be just as important as the actual codes
executed for performance. You would have much more control over working
set/memory if you used C/C++.
王在祥 wrote:
>I think the speed and performance is determine by：
>1, the JIT qualilty. Since a C based JIT and Java JIT both generate machine
>code, there should be less difference, only difference from the JIT alogrith
>2. other runtime service such as allocation, GC, thread and synchornization.
>But it also depends on the alogrith and not the language itself.
>
>
>
>
>>How about speed? [not criticizing, just curious]
>>
>>--
>>Stefano.
>>
>>
>>
>>
Re: I hope the JVM implements most using Java itself
Posted by 王在祥 <wa...@gmail.com>.
I think the speed and performance is determine by：
1, the JIT qualilty. Since a C based JIT and Java JIT both generate machine
code, there should be less difference, only difference from the JIT alogrith
2. other runtime service such as allocation, GC, thread and synchornization.
But it also depends on the alogrith and not the language itself.
>
> How about speed? [not criticizing, just curious]
>
> --
> Stefano.
>
>
Re: I hope the JVM implements most using Java itself
Posted by Stefano Mazzocchi <st...@apache.org>.
王在祥 wrote:
> Hotspot is coded in C/C++, but I hope Harmony to choice Java as its major
> language. there is the reasons:
>
> 1. Implement a JVM using Java is possible and effecitive enough, like the
> JikesRVM, jode etc.
> 2. Java code has good feature for maintaince and reabability than C/C++, and
> it will enable more Java fans to understand and contribute to the project.
> 3. a full compatible JVM implemented using Java is an exciting news for the
> java world
> 4. Since there is already hotspot that works well, Harmony should focus
> mostly on new technology and more good architecture, not the times to
> complete the project.
> 5. A Java JVM will improve the Java/JVM technology such as GC, synchronize
> and etc, to enable the JVM as fast as possible.
How about speed? [not criticizing, just curious]
--
Stefano.