Terminology etc
I thought it might be helpful to clarify some terminology and a few technical issues. Corrections/improvements/clarifications welcome ;-) VM core The precise composition of the VM core is open to discussion and debate. However, I think a safe, broad definition of it is that part of the VM which brings together the major components such as JITs, classloaders, scheduler, and GC. It's the hub in the wheel and is responsible for the main VM bootstrap (bootstrapping the classloader, starting the scheduler, memory manager, compiler etc). VM bootstrap The bootstrap of the VM has a number of elements to it, including gathering command line arguments, and starting the various components (above). In the context of a Java-in-Java VM, the above is all written in Java. VM boot image The boot image is an image of a VM heap constructed ahead of time and populated with Java objects including code objects corresponding to the VM core and other elements of the VM necessary for the VM bootstrap (all written in Java, compiled ahead of time, packaged into Java objects and composed into a boot image). The boot image construction phase requires a working host VM (ideally the VM is self-hosting). VM bootloader In the case of Jikes RVM a dozen or so lines of assember and a few lines of C are required to basically do the job of any boot loader loader---mmap a boot image and throw the instruction pointer into it. It will also marshal argv and make it available to the VM core. This is technically interesting, but actually pretty trivial and has little to do with the VM core (aside from ensuring the instruction pointer lands a nice place within the boot image ;-) OS interface The VM must talk to the OS (for file IO, signal handling, etc). There is not a whole lot to it, but a Java wrapper around OS functionality is required if the VM is java-in-java. This wrapper is pretty trivial and one half of it will (by necessity) be written in C. I hope this brief sketch provides folks with a slightly clearer view of what a java-in-java VM looks like, and some (tentitive) terminology we can use to ensure we're not talking at cross purposes. Cheers, --Steve
Re: Terminology etc
2005/5/24, Steve Blackburn [EMAIL PROTECTED]: I thought it might be helpful to clarify some terminology and a few technical issues. Corrections/improvements/clarifications welcome ;-) Scheduled for translation... Raffaele
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Archie Cobbs wrote: Nick Lothian wrote: According to http://www.csc.uvic.ca/~csc586a/Ass1.pdf JamVm lacks a bytecode verifier, too. Seems like most O/S VM's don't have one (including JC)... Gcj, leading the way, has two, or three by now :) Kaffe and CacaoJVM also have their own implementations, and JikesRVM as well, afaik. The plan for Kaffe is to merge in the gcjx verifier, and try to standardise on a commonly maintained verifier component, to make sure we fix the security issues once, instead of fixing them everywhere:) cheers, dalibor topic
Re: Terminology etc
This is excellent! For one, I find Java-in-Java to be much clearer after this little set of definitions. A quick proposal: perhaps VM bootstrap as used below should really be something like VM initialization, VM init, or even VM startup, since the word bootstrap is very specific and to me at least, indicates something more akin to the VM bootloader + VM boot image (as used below). I'm going to try to make a couple of observations. Please forgive the rambling :) It just seems like things are starting to take shape... * It looks like there is really not much in common between this architecture and one where VM core would be in C... For that one, VM core would be in C, as would be all of the components, such as GC, scheduler, etc. VM init doesn't sound like a big deal but would probably also be in C. VM boot image and the VM bootloader are simply not present in a C solution. * OS interface is perhaps one place where some code can be shared. If C version can benefit from an OS abstraction layer for portability, then it seems like this layer could be shared between the C and the Java implementations. * The meat of the VM seems to be in the spokes that connect to the VM core-hub. It seems that this is where it would make the most sense to mix components written in C with those written in Java, to see which one can do a better job. If all spokes were in C, it would make little sense to have the hub be in Java... On the other hand if spokes are all Java, it makes little sense to have the hub be in C. Steve, if the spokes were in Java but the hub in C, would we then lose all of the aggressive inlining benefits that Java-in-Java solution can provide? -dmitry Steve Blackburn wrote: I thought it might be helpful to clarify some terminology and a few technical issues. Corrections/improvements/clarifications welcome ;-) VM core The precise composition of the VM core is open to discussion and debate. However, I think a safe, broad definition of it is that part of the VM which brings together the major components such as JITs, classloaders, scheduler, and GC. It's the hub in the wheel and is responsible for the main VM bootstrap (bootstrapping the classloader, starting the scheduler, memory manager, compiler etc). VM bootstrap The bootstrap of the VM has a number of elements to it, including gathering command line arguments, and starting the various components (above). In the context of a Java-in-Java VM, the above is all written in Java. VM boot image The boot image is an image of a VM heap constructed ahead of time and populated with Java objects including code objects corresponding to the VM core and other elements of the VM necessary for the VM bootstrap (all written in Java, compiled ahead of time, packaged into Java objects and composed into a boot image). The boot image construction phase requires a working host VM (ideally the VM is self-hosting). VM bootloader In the case of Jikes RVM a dozen or so lines of assember and a few lines of C are required to basically do the job of any boot loader loader---mmap a boot image and throw the instruction pointer into it. It will also marshal argv and make it available to the VM core. This is technically interesting, but actually pretty trivial and has little to do with the VM core (aside from ensuring the instruction pointer lands a nice place within the boot image ;-) OS interface The VM must talk to the OS (for file IO, signal handling, etc). There is not a whole lot to it, but a Java wrapper around OS functionality is required if the VM is java-in-java. This wrapper is pretty trivial and one half of it will (by necessity) be written in C. I hope this brief sketch provides folks with a slightly clearer view of what a java-in-java VM looks like, and some (tentitive) terminology we can use to ensure we're not talking at cross purposes. Cheers, --Steve
Re: Terminology etc
(BA$B!!(Bquestion (sorry)$B!'(B would it include realtime capabilities? (BCurrent (Bsystems are sometimes real nightmares from this point of view and it is a (Bmust have for embedded systems... (B (B (BI certainly hope so... I don't believe it is beyond us to achieve that. (BThat is another area where the OVM experience may be particularly (Bhelpful. As to the technical practicality of such a broad-ranging goal, (Bthe j9 VM is as ambitious as this... (B (BCheers, (B (B--Steve
Re: Terminology etc
Hi, on the subject of terminology, when you say scheduling, what do you mean exactly? Are you talking about monitors and other sync issues or are you talking about some kind of m:n thread scheduling? Or neither? :) Cheers, Dave On 5/24/05, Steve Blackburn [EMAIL PROTECTED] wrote: Dmitry Serebrennikov wrote: A quick proposal: perhaps VM bootstrap as used below should really be something like VM initialization, VM init, or even VM startup, since the word bootstrap is very specific and to me at least, indicates something more akin to the VM bootloader + VM boot image (as used below). That sounds fine with me. It is hard to move outside one's own (limited) terminology :-). We have boot() methods on each of the key components and a boot() method in the vm core which calls these. That's the origins of my terminology. Init seems reasonable and disambiguates the role of the bootloader. Probably the original rationale for using the boot word is that there is a higher level of bootstrapping going on here---getting the classloader loaded before you have a class loader ;-) etc etc. But I agree, init may be helpful. * OS interface is perhaps one place where some code can be shared. If C version can benefit from an OS abstraction layer for portability, then it seems like this layer could be shared between the C and the Java implementations. I agree. It turns out to be a tiny amount of code though (in the case of Jikes RVM, at least). * The meat of the VM seems to be in the spokes that connect to the VM core-hub. It seems that this is where it would make the most sense to mix components written in C with those written in Java, to see which one can do a better job. If all spokes were in C, it would make little sense to have the hub be in Java... On the other hand if spokes are all Java, it makes little sense to have the hub be in C. Steve, if the spokes were in Java but the hub in C, would we then lose all of the aggressive inlining benefits that Java-in-Java solution can provide? I don't know. These are really interesting questions and ones I think we need to hear lots of informed opinion on. My experience with mixing C Java inside the VM is limited to the interface to the MM. The inlining issue is key there because of the fine grain at which those interactions occur. Scheduling, compilation and classloading are very much coarser grained, so those issues are much less critical there... Cheers, --Steve
Re: Terminology etc
2005/5/24, David Griffiths [EMAIL PROTECTED]: Hi, on the subject of terminology, when you say scheduling, what do you mean exactly? Are you talking about monitors and other sync issues or are you talking about some kind of m:n thread scheduling? Or neither? :) I'm talking about that I'm translating the http://wiki.apache.org/harmony/HarmonyArchitecture, and after that I will translate this glossary... Probably it's the best I can do, actually...I'm not a professional translator, but probably I can do a better job than google translator! :) My bests... Raffaele
Re: Sun lashes out at open source J2SE
Isn't the message here: Gosling misunderstands the point of Harmony? Anyone reading to the bottom of the article will be put right. Just a quick question tho'. The article mentions portability and distribution licensing. Isn't another part of the point that an OSS virtual machine (with the backing of a big foundation like apache) will be able to take advantage of the 'many eyes' principle, for bug reports/fixes and performance enhancements? On 5/24/05, Mladen Turk [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Eh. Lets just keep to our purpose and message of compatibility and openness. When we move from 'enthusiasm' to the 'project' more and more 'doubts' will be seen :) Let's just play our song and let others have all the doubts they wish. Regards, Mladen.
Re: Other interesting papers and research
[EMAIL PROTECTED] wrote: They automatically build themselves simple JIT backends (by extracting fragments produced by the ahead of time compiler). This sounds like a great way to achieve portability while achiving better performance than a conventional interpreter. I guess it's a bit better or just comparable with a good interpreter. They say it is a lot better: speedups of up to 1.87 over the fastest previous interpreter based technique, and performance comparable to simple native code compilers. The effort required for retargeting our implementation from the 386 to the PPC architecture was less than a person day. In 1998, I have written such a JIT compiler concatinate code fragments generated by GCC for each JVM instruction. Very interesting! Unfortunately, the JIT was slightly slower than an interpreter in Sun's Classic VM. The interpreter was written in x86 assembly language and implements dynamic stack caching with 2 registers and 3 states. It performs much better than the previous interpreter written in C. Then I rewrote the JIT. It would be interesting to hear your perspective on Ertl Gregg's approach. Did they do something you had not done? Do they have any particular insight? You are in an excellent position to make a critical assessment of their work. I am not very sure which is better for us, having a portable and so-so baseline compiler or a good interpreter which is possibly less portable than the compiler. There will be a trade off between memory consumption, portability and so on. Ideally we will have both as components and the capacity to choose either or both depending on the build we are targetting. Cheers, --Steve
Re: Terminology etc
I've added this to the wiki and linked from the main page. - Original Message - From: Steve Blackburn [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Tuesday, May 24, 2005 8:05 AM Subject: Terminology etc I thought it might be helpful to clarify some terminology and a few technical issues. Corrections/improvements/clarifications welcome ;-) VM core The precise composition of the VM core is open to discussion and debate. However, I think a safe, broad definition of it is that part of the VM which brings together the major components such as JITs, classloaders, scheduler, and GC. It's the hub in the wheel and is responsible for the main VM bootstrap (bootstrapping the classloader, starting the scheduler, memory manager, compiler etc). VM bootstrap The bootstrap of the VM has a number of elements to it, including gathering command line arguments, and starting the various components (above). In the context of a Java-in-Java VM, the above is all written in Java. VM boot image The boot image is an image of a VM heap constructed ahead of time and populated with Java objects including code objects corresponding to the VM core and other elements of the VM necessary for the VM bootstrap (all written in Java, compiled ahead of time, packaged into Java objects and composed into a boot image). The boot image construction phase requires a working host VM (ideally the VM is self-hosting). VM bootloader In the case of Jikes RVM a dozen or so lines of assember and a few lines of C are required to basically do the job of any boot loader loader---mmap a boot image and throw the instruction pointer into it. It will also marshal argv and make it available to the VM core. This is technically interesting, but actually pretty trivial and has little to do with the VM core (aside from ensuring the instruction pointer lands a nice place within the boot image ;-) OS interface The VM must talk to the OS (for file IO, signal handling, etc). There is not a whole lot to it, but a Java wrapper around OS functionality is required if the VM is java-in-java. This wrapper is pretty trivial and one half of it will (by necessity) be written in C. I hope this brief sketch provides folks with a slightly clearer view of what a java-in-java VM looks like, and some (tentitive) terminology we can use to ensure we're not talking at cross purposes. Cheers, --Steve
Re: Terminology etc
There isn't much space for plugability of components beyond compile-link
time. And I see no reason to have it otherwise.
Rodrigo
On 5/24/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On May 24, 2005, at 4:49 AM, Dmitry Serebrennikov wrote:
* OS interface is perhaps one place where some code can be
shared. If C version can benefit from an OS abstraction layer for
portability, then it seems like this layer could be shared between
the C and the Java implementations.
I'm really hoping we can shelve the idea of having a C implementation
and a Java implementation. I think we should try to mix them into
one solution.
Steve, if the spokes were in Java but the hub in C, would we then
lose all of the aggressive inlining benefits that Java-in-Java
solution can provide?
I'll preface this and state that I have no idea what I'm talking
about. That said, this reminds me a little of what was done in the
Geronimo architecture that makes it differ from component
architectures that use central mechanisms like JMX to let modules/
components communicate. With Geronimo, the components are given
references to their dependencies, rather than having them work
through the central bus to talk between dependencies. This gives a
big speedup, as the overhead goes away. (Ok, there are 'smart'
proxies between the components, but that's a detail we can ignore here.
I've guessed (and steve confirmed) that the boundaries between the
modules in a VM aren't flat APIs, but something thicker, with a
good bit of interdependency. So I'd guess that while a central hub
would be used to let the modules resolve dependencies (The JIT needs
to talk to the GC and vice versa), it would be something on the order
of asking the 'hub' (won't use 'core') for something, and getting an
object back that could be as sophisticated as needed.
I'd sure like to see some of the existing thinking on this from the
JikesVM peeps
As an aside to my aside, Ben and I were musing over ways to do things
like this, because we thought that in a multi-language-capable VM,
you'd probably define some minimum interface APIs so that parts in
different languages would have framework support for
intercommunication, but also provide a discovery mechanism to so
that like-minded components could talk in a more private, direct way.
For example, suppose we are able to define the boundary between GC
and JIT in a nice way, we'd want any object claiming to be a JIT to
support that standard API and be able to provide an to the hub to be
given to any other module an implementation of that interface. So
you could do any kind of JIT implementation or experimentation and
plug it in.
However, if I wrote both the JIT and GC, I would want my JIT and GC
to discover that and give each other a private API that took
advantage of each other's internals. Something like what we used to
do with COM and QueryInterface, starting with something basic and
standard, and grubbing around in it to find something better.
Loosely speaking :
interface Discovery {
Object queryInterface(UUID interfaceID);
}
interface JIT extends Discovery {
// JIT API here
}
So in my GC implementation, an init() call that's involved when it's
being created :
void init(Discovery hubDiscovery) {
JIT commonJIT = (JIT) hubDiscovery.queryInterface
(UUID_FOR_STANDARD_JIT_API);
// now lets see if this JIT knows the secret handshake
CustomJIT goodJIT = (JIT) commonJIT.queryInterface
(UUID_FOR_JIT_I_ALSO_WROTE);
if (goodJIT != null) {
}
}
and in my JIT implementation :
Object queryInterface(UUID id) {
if (UUID_FOR_STANDARD_JIT_API.equals(id)) {
return this;
}
if (UUID_FOR_JIT_I_ALSO_WROTE.equals(id)) {
return myInternalCustomJIT;
return null;
}
Anyway, this reminded me of what Ben and I were talking about a few
days ago. Note that a) I'm just making this up, b) all the above is
trying to capture some loose ideas on the subject, and c)
disclaimer is all done pre-coffee in a strange hotel room after
waking up /disclaimer
geir
-dmitry
Steve Blackburn wrote:
I thought it might be helpful to clarify some terminology and a few
technical issues. Corrections/improvements/clarifications
welcome ;-)
VM core
The precise composition of the VM core is open to discussion and
debate. However, I think a safe, broad definition of it is that
part of the VM which brings together the major components such as
JITs, classloaders, scheduler, and GC. It's the hub in the wheel
and is responsible for the main VM bootstrap (bootstrapping the
classloader, starting the scheduler, memory manager, compiler etc).
VM bootstrap
The bootstrap of the VM has a number of elements to it, including
gathering command line arguments, and starting the various
components (above).
In the context of a Java-in-Java VM, the above is all written in
Java.
VM
[Harmony Wiki] Update of FrontPage by Upayavira
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by Upayavira: http://wiki.apache.org/harmony/FrontPage The comment on the change is: Trivial change to test commit messages. -- * [TechnicalFAQ] * [HarmonyArchitecture] Proposed Harmony Architecture (Overview) - + == Resources == * [http://svn.apache.org/repos/asf/incubator/harmony/ SVN] * [http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740 JIRA]
Re: Bootstrapping community (Re: [arch] The Third Way : C/C++ and Java and lets go forward)
we are talking cross-purposes...i can't keep up with all the traffic. Are u sure, you haven't missed a nugget of information here and there? Am not saying that you should not pick Jam. Pick jam, but there are others who are willing to help and willing to write code and have contributions to bring in. *PLEASE* bring them in sooner than later. You know how bloody long it takes us to do the paperwork and get the infrastructure work done. Let's have the discussions on the mailing list. Document them say using java interfaces in SVN. Put up information on the wiki to back up the discussions. Let folks write some non-trivial code that is needed eventually but does not hinder your kernel work/discussions. For example, someone was going to write a javac wrapper for jdt. How do know which pieces of information on the mailing list you considered for taking a decision. and someone may use a totally different set of points made on the mailing list for taking the opposite decision. We need to document those in the design docs and/or wiki. Call me today and we can chat a bit more. thanks, dims On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 23, 2005, at 11:03 PM, Davanum Srinivas wrote: Geir, Am not sure u understood where i am coming from. (I feel that u saying that we are not going to get commit privs for folks interested till the design discussions are over AND that design decisions are going to be made on the mailing list ONLY?) Huh? I don't understand that. What I want to do is start getting people working and committing, but *also* getting some of the sophisticated design work done. I think that we can drive one from another and vice-versa. By having a little kernel-thingy (I won't call it core because after talking to Steve, it's clearly a matter of semantics) that's for our prototyping and learning, we can start working with the modularization, which as I understand it, is a current topic in VM research. Yes, I'm hoping the design decisions are made on the list, btw. :) I have trouble keeping up with the mailing list and so do others...am not saying that we have to check-in code from all the seed VM's into our repo. I want to keep the momentum going by getting committers on board, letting them share thoughts, documents and code if any (SVN repo?), may be use JIRA to document requirements etc. Right now no one knows who is going to be working and on what and how to contribute etc. Yes - that's the entire point of what I'm trying to do :) As stefano says - good ideas and bad code build communities, the other three combinations do notLet's build the community without waiting for the discussion to end on the mailing lists and let the committers/community decide on how best to move forward. We don't (mentors) have to pick the winner? do we? There's no winner. LIke I said, this isn't about blessing one thing as the solution. We aren't going to just take something from outside and say done. What I wanted is code to experiment with and adapt to what *we* design. We can add things from elsewhere as the design require (like modularize parts of JikesRVM, which I understand needs to be done...). Look at Jam. My understanding is that it sorta works, and it's very simple. It sounds like it's easy to refactor to a small, kernel- thingy that will be a basis of support for moving forward w/ the modularity. And then we can throw it out :) or not. Whatever we discover. I think we're going to learn a lot here. geir (And while I'm a mentor, I'm also a participant :) Thanks, dims On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 23, 2005, at 9:54 PM, Davanum Srinivas wrote: Geir, Am convinced that we can write a JVM in pure java with minimal C/C ++. Why? If it has C/C++, it's not pure Java. Period. This isn't about whether or not that it can be done in Java, or a way to get it into C/C++. Lets get over that misconception right now. I'm sure that major parts can be done in Java - it's been demonstrated by JikesRVM, and lots of experienced VM people point in that direction, even with a C/C++ core. I have no problem with that. How about we poll the VM candidates on who wants to help seed the project, ask them to do the paperwork, then we can get folks on board as committers and let them play in sandboxes (see below). Folks who do the work will then get to decide the future direction. We don't have to make the technical decision now before the committers are on board. What do you think? I don't see what we gain. We want to create *our design*, not make frankenVM. The point of starting with a small seed C/C++ kernel is to get the bootstrap and intrinsics support that *any* VM will need, pure C, pure Java, or mixed. Our discussions will point to where we have to refactor. On top of that, we build what we
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Peter Donald wrote: Hi, Steve Blackburn wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. You could be right in that it is a technical mistake but in the long wrong it may prove not to be useful for helping to kick start the community and thus not a community mistake. Discussion about abstract concepts and implementation strategies with no concrete code that people can look at and play with can lead to never ending discussions that never seem to progress. Give people some code and some leeway to experiment for themselves and they are much more likely to come around to understanding the problem and thus being able to agree on a way forward. Paraphrasing what was said earlier in this mailing list crap code and good ideas will lead to a good community while other combinations may not. Experimenting with a codebase will at least give people a feel for other members of the community and how they cut code. This will be worth it even if the entire codebase gets thrown out or rewritten from scratch. Some of the people here are unlikely to be swayed from C/C++ for VM crowd with just words - code which they can profile and generate performance statistics with is much more likely to convince them. Don't get me wrong - discussion is good and you have convinced me (who was firmly in the C for VM camp) that Java In Java is a good approach - I would love to hear more about it (especially how synchronization, volatile and monitors could be plugged in) but there has been enough talk and probably a good time for action to start ;) So I agree with you that this move may be a technical mistake but I would put forth the idea that it may be a bigger community mistake if something concrete does not start soon. FWIW I am not involved with Apache or any of the VM/Classpath projects but I suspect that this is a way forward that would be useful using the Apache way. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). I guess I was under the wrong impression aswell. I thought that JRVM required another JVM during build to compile its own codebase and create an executable image. JRVM would then use this image during its execution. Could we use a simple interpreter for this initial stage? Or am I completely off base. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I don't disagree with you but I guess I think it would be more useful to place community correctnes over technical correctnes at the begining. Once a group is working together they should be able to migrate to JRVM or whatever could be used as the bases. I very much resonate with Peter. Peter and I (and Leo) have scars all over out virtual bodies for the years of journey in Apache Avalon, where we traded architectural correctness over community wisdom. Failing miserably. The Avalon Project went down in flames. The simple technical disagreements became poisonous (and clever) personal attacks, in order to undermine the technical opponents and convince the community of the value of their position. Experienced Apache members and board directors spent years dealing with the social fallout of that project. It took 2 years for the ASF to kill avalon. If you ask all the participants, they will never go back. They know now how to accept disagreement, but more, how the 'perfect architecture' is a holy grail. Do the simplest thing that can possibly work for you and move on, the community is an incredibly powerful engine, it's better to learn how to use it than not. Now Avalon is dead and nobody is missing it. For a lot of us, it's a monument to the death of the old software engineering school applied to open development. A mythical land. A place that so many want to see existing that are willing to sacrifice a lot for it... but it nevertheless can't be reached, just like the real Avalon, King Arthur's tomb. I am the one who proposed Avalon, in 1998, with the intention of creating a 'kernel' for servers (before OSGi, before jboss mbeans, before geronimo's mbeans). I am the one who worked thru to kill it: despite the great deal of technological advancement that was
Re: Sun lashes out at open source J2SE
Geir Magnusson Jr. wrote: Eh. Lets just keep to our purpose and message of compatibility and openness. I'm familiar with getting misquoted, or pieces taken out of context, and I hope this is the case here. Yeah. I understand where James Gosling is coming from: he is concerned about 'forking' and I understand that. But he has to undertand that forking the codebase and forking the functionality are two different things. The artistic license, for example, allows you to fork the code *ONLY* if you change all the APIs issues. I think somebody has to go down to his office and let him know at least that, I think he has a little stereotypical view of open source and thinks that we are all tinfoil hats. But you see why a lot of people got burned in talking to Sun: you can't show them the value of a community if their top management thinks that no real software architect would ever work with a bunch of slashdot freaks. Pretty blind, actually. Especially because Apache created more code and value for the Java platform than anybody else. Oh well. He does not understand our clear need to have a truly open code, because he does *NOT* understand that we don't want the right to fork the java platform (we can't call it java if we do, so what's the point!), but we want the right to build a community around it. Sun licenses don't give us that, therefore the need for Harmony. But at the end, who cares: the JCP license allows us to do it, and our not-for-profit status allows us to have access to the TCK for free. We will not need words to show James Gosling that, ultimately, Harmony is not going to be disruptive, but rather beneficial. And the reason for this is that we value compatibility even more than he does: because a lot of our salaries depend on it! Let's get to work. -- Stefano.
[Harmony Wiki] Update of People by DavanumSrinivas
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by DavanumSrinivas: http://wiki.apache.org/harmony/People -- == Folks with prior VM experience (Alphabetical) == + || Name || Email || VM related project || Interested in becoming a Committer? || || Renaud BECHADE || renaud.bechade AT numerix.com || ??? || - || Steve Blackburn || Steve.Blackburn AT anu.edu.au || [http://jikes.sourceforge.net/ JikesRVM] || + || Steve Blackburn || Steve.Blackburn AT anu.edu.au || [http://jikes.sourceforge.net/ JikesRVM] || Yes || || Guy Churchward || ??? || ??? || || Archie Cobbs || archie AT dellroad.org || [http://jcvm.sourceforge.net/ JCVM] || || Joakim Dahlstedt || ??? || ??? || @@ -19, +20 @@ || Nicolas Cannasse || ncannasse AT motion-twin.com || [http://ncannasse.free.fr MotionTypes VM] || == All others with Open source experience if any (Alphabetical) == + || Name || Email || VM related project || Interested in becoming a Committer? || || Thorbjørn Ravn Andersen||thunderbear AT yahoo.com|| || || Matt Benson || mbenson AT apache.org || Ant/Jext/iText || || Ricky Clarkson || ricky_clarkson AT yahoo.com || Some patches, lots of talk! ||
[Harmony Wiki] Update of People by MladenTurk
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by MladenTurk: http://wiki.apache.org/harmony/People -- || Tony McCrary || [EMAIL PROTECTED] || ??? || || Raffaele Castagno || raffaele.castagno AT gmail.com || Available for translation to Italian of Harmony docs || || Panagiotis Astithas || past AT ebs.gr || ??? || + || Mladen Turk || mturk AT apache.org || Httpd/APR/Tomcat/Commons || Yes ||
People - Take #2
Folks, Please free to add yourself to the People page - http://wiki.apache.org/harmony/People. There is a new field where you can indicate your willingness to become a committer :) [We are still in the process of deciding the details of how/who/when/what of the bootstrapping process...but this is a way for you to tell us you are interested]. thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/
[Harmony Wiki] Update of People by AgustiDosaiguas
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by AgustiDosaiguas: http://wiki.apache.org/harmony/People -- || Matt Benson || mbenson AT apache.org || Ant/Jext/iText || || Ricky Clarkson || ricky_clarkson AT yahoo.com || Some patches, lots of talk! || || [:IanDarwin:Ian Darwin] || ian62 AT darwinsys.com || Tomcat/OpenBSD/etc || - || Agustí Dosaiguas || agusti AT dosaiguas.net || ??? || + || Agustí Dosaiguas || agusti AT dosaiguas.net || || Yes || || Ben Laurie || ben AT algroup.co.uk || httpd/security || || NickLothian || nlothian AT apache.org || Pluto/Other Stuff|| || Geir Magnusson Jr. || geirm AT apache.org || Geronimo/Agila ||
[Harmony Wiki] Update of FrontPage by ArchieCobbs
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by ArchieCobbs: http://wiki.apache.org/harmony/FrontPage -- == Volunteers with contributions == - * [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/[EMAIL PROTECTED] Archie Cobb - JCVM] + * [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/[EMAIL PROTECTED] Archie Cobbs - JCVM] == Random Thoughts ==
[Harmony Wiki] Update of People by SimonChappell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by SimonChappell: http://wiki.apache.org/harmony/People -- || Name || Email || VM related project || Interested in becoming a Committer? || || Thorbjørn Ravn Andersen||thunderbear AT yahoo.com|| || Yes || || Matt Benson || mbenson AT apache.org || Ant/Jext/iText || + || SimonChappell || simonpeterchappell AT gmail.com || Java programmer and Technical Lead || || Ricky Clarkson || ricky_clarkson AT yahoo.com || Some patches, lots of talk! || || [:IanDarwin:Ian Darwin] || ian62 AT darwinsys.com || Tomcat/OpenBSD/etc || || Agustí Dosaiguas || agusti AT dosaiguas.net || || Yes ||
[Harmony Wiki] Update of People by MattBenson
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by MattBenson: http://wiki.apache.org/harmony/People -- || Nicolas Cannasse || ncannasse AT motion-twin.com || [http://ncannasse.free.fr MotionTypes VM] || == All others with Open source experience if any (Alphabetical) == - || Name || Email || VM related project || Interested in becoming a Committer? || + || Name || Email || Open source project || Interested in becoming a Committer? || || Thorbjørn Ravn Andersen||thunderbear AT yahoo.com|| || Yes || - || Matt Benson || mbenson AT apache.org || Ant/Jext/iText || + || Matt Benson || mbenson AT apache.org || Ant/Jext/iText || Yes || || SimonChappell || simonpeterchappell AT gmail.com || Java programmer and Technical Lead || || Ricky Clarkson || ricky_clarkson AT yahoo.com || Some patches, lots of talk! || || [:IanDarwin:Ian Darwin] || ian62 AT darwinsys.com || Tomcat/OpenBSD/etc ||
[Harmony Wiki] Update of People by TonyMcCrary
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by TonyMcCrary: http://wiki.apache.org/harmony/People -- || Vikram Mohan || [http://www.aldubai.com/email/ Email Me] || [http://www.FaeLLe.com/ Java and Technology Blog] || || Ozgur Akan || akan AT aiqa.com || www.projectme.org || || Juan Leyva || familialeyva AT yahoo.es || small projects,patches || - || Tony McCrary || [EMAIL PROTECTED] || ??? || + || Tony McCrary || [EMAIL PROTECTED] || ??? || Yes || || Raffaele Castagno || raffaele.castagno AT gmail.com || Available for translation to Italian of Harmony docs || || Panagiotis Astithas || past AT ebs.gr || ??? || || Mladen Turk || mturk AT apache.org || Httpd/APR/Tomcat/Commons || Yes ||
[Harmony Wiki] Update of SimonChappell by SimonChappell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by SimonChappell: http://wiki.apache.org/harmony/SimonChappell New page: #format wiki #language en == Simon P. Chappell == Email: [[MailTo(simonpeterchappell AT SPAMFREE gmail DOT com)]] or [[MailTo(simon AT SPAMFREE simonpeter DOT com)]] A British guy living and working in the United States. I was introduced to computers in 1980, owning my first one (a Sinclair ZX81) in 1981. I started with Java in the 1997/1998 timeframe, and have been working with it ever since, first as a programmer and for the last four years as a Technical Lead/Mentor. Far more information than most people would ever want to know about me is on my personal website: http://www.simonpeter.com/. Naturally, I have a blog: http://uab.blogspot.com/. CategoryHomepage
[Harmony Wiki] Update of JVM Implementation Ideas by ArchieCobbs
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by ArchieCobbs: http://wiki.apache.org/harmony/JVM_Implementation_Ideas -- - This is a list of various useful design ideas and implementation tricks that may be desirable to include in Harmony. = Per-class loader memory areas = + * Idea: class loaders and all their defined classes are unloaded all at once. Memory is allocated and not freed until that happens, so allocation behavior is stack-like. Instead of using the more general and therefore costly malloc() or the Java heap for class loader specific memory, use a lighter weight, stack like memory subsystem. In addition, all java.lang.Class objects can be stored in per-class loader memory instead of in the normal heap, reducing work for the GC subsystem. - * Idea: class loaders and all their defined classes are unloaded - all at once. Memory is allocated and not freed until that happens, - so allocation behavior is stack-like. Instead of using the more - general and therefore costly malloc() or the Java heap for - class loader specific memory, use a lighter weight, stack like - memory subsystem. - * Advantages: more efficient, makes class loader unloading easier + * Advantages: more efficient, makes class loader unloading easier - * Disadvantages: none + * Disadvantages: if java.lang.Class objects are stored in per-loader memory, their references must be tracked manually. - * Origin: SableVM + * Origin: SableVM = Bi-directional object layout = + * Idea: let objects' primitive fields grow upward from the object head and let reference fields grow downward from the object head. Object pointers pointing to objects themselves containing object references therefore point into the middle of the object's memory area. + * Advantages: all object references are contiguous, which makes following these references during garbage collection, etc. easier and simpler. + * Disadvantages: object head (lockword, vtable pointer, etc) is not necessarily at the beginning of an object's memory area, which can mean extra work to find the head when iterating through the heap e.g. during mark/sweep GC. - * Idea: let objects' primitive fields grow upward from the object - head and let reference fields grow downward from the object head. - Object pointers pointing to objects themselves containing object - references therefore point into the middle of the object's memory - area. - * Advantages: all object references are contiguous, which makes - following these references during garbage collection, etc. easier - and simpler. - * Disadvantages: object head (lockword, vtable pointer, etc) - is not necessarily at the beginning of an object's memory area, - which can mean extra work to find the head when iterating through - the heap e.g. during mark/sweep GC. - * Origin: SableVM + * Origin: SableVM = Spinless thin-locks = + * Idea: compare-and-swap instruction used to grab an object lock in the common case of no contention, otherwise fall back to mutexes. - * Idea: compare-and-swap instruction used to grab an object lock - in the common case of no contention, otherwise fall back to mutexes. - * Advantages: very efficient + * Advantages: very efficient - * Disadvantages: some assembly required + * Disadvantages: some assembly required - * Origin: lots of people. SableVM has a nice version of this algorithm. + * Origin: lots of people. SableVM has a nice version of this algorithm. + = SableVM thread state tracking = + + * Idea: use compare-and-swap to transition threads from running in Java mode vs. running in native mode, and to detect a stop the world operation. When a Java thread goes into native mode, i.e., it invokes a JNI function or some other blocking system call like pthread_cond_wait(), it has to detach itself in some sense from the JVM so that the JVM doesn't get stuck waiting indefinitely for it to return. + * Advantages: efficient implementation + * Disadvantages: none known\ + * Origin: SableVM +
[Harmony Wiki] Update of JVM Implementation Ideas by ArchieCobbs
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by ArchieCobbs: http://wiki.apache.org/harmony/JVM_Implementation_Ideas -- This is a list of various useful design ideas and implementation tricks that may be desirable to include in Harmony. - = Per-class loader memory areas = + === Per-class loader memory areas === * Idea: class loaders and all their defined classes are unloaded all at once. Memory is allocated and not freed until that happens, so allocation behavior is stack-like. Instead of using the more general and therefore costly malloc() or the Java heap for class loader specific memory, use a lighter weight, stack like memory subsystem. In addition, all java.lang.Class objects can be stored in per-class loader memory instead of in the normal heap, reducing work for the GC subsystem. * Advantages: more efficient, makes class loader unloading easier * Disadvantages: if java.lang.Class objects are stored in per-loader memory, their references must be tracked manually. + * Comments: this one is pretty much a no brainer * Origin: SableVM - = Bi-directional object layout = + === Bi-directional object layout === * Idea: let objects' primitive fields grow upward from the object head and let reference fields grow downward from the object head. Object pointers pointing to objects themselves containing object references therefore point into the middle of the object's memory area. * Advantages: all object references are contiguous, which makes following these references during garbage collection, etc. easier and simpler. * Disadvantages: object head (lockword, vtable pointer, etc) is not necessarily at the beginning of an object's memory area, which can mean extra work to find the head when iterating through the heap e.g. during mark/sweep GC. * Origin: SableVM - = Spinless thin-locks = + === Spinless thin-locks === * Idea: compare-and-swap instruction used to grab an object lock in the common case of no contention, otherwise fall back to mutexes. * Advantages: very efficient * Disadvantages: some assembly required + * Comments: using some form of thin locks is a no-brainer * Origin: lots of people. SableVM has a nice version of this algorithm. - = SableVM thread state tracking = + === SableVM thread state tracking === * Idea: use compare-and-swap to transition threads from running in Java mode vs. running in native mode, and to detect a stop the world operation. When a Java thread goes into native mode, i.e., it invokes a JNI function or some other blocking system call like pthread_cond_wait(), it has to detach itself in some sense from the JVM so that the JVM doesn't get stuck waiting indefinitely for it to return. - * Advantages: efficient implementation + * Advantages: very efficient implementation for Java locking - * Disadvantages: none known\ + * Disadvantages: none known * Origin: SableVM + == Signals for thread notification === + + * Idea: threads must periodically check whether they need to do something. Typically this is done at backward branches. To make this check efficient, have the thread read a byte from a well-known page of mmap()'d memory. When another thread wants the thread to check-in, it simply maps that page unreadable. The target thread gets a signal, + does whatever check required, the page is re-mapped readable, and the target thread returns from the signal and continues on its merry way. + * Advantages: efficient way to enforce checking in + * Disadvantages: requires mmap() and signals + * Origin: unknown/multiple; implemented in lots of places. +
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Peter Donald wrote: Are you suggesting we do it w/ JC? :) Is there a single copyright holder such I'll have to abstain from the voting on that :-) I am not sure why not :) I think that what Geir is proposing is that Harmony start from some exisitng codebase that is hacking on and reworked as part of a learning experience for everyone as part of a stepping stone before the real VM is rewritten once the committers understand the space (community and technical). If you think JC is a good place to start for this then speak up - but you must realize that it may end up being hacked a million different ways and not look like JC at all in the end. And it may get thrown out as people start on the next VM. If you are comfortable with that then ... I have no problem with that.. with a project like this everyone has to accept that creative destruction will happen and not be afraid to alter cherised paradigms along the way. If taking the check in an existing VM and start hacking on it approach then probably JC is as good a candidate as any. Both you and Steve have suggested the same sort of approach - namely that Harmony look at different ideas implemented in different JVMs and scoop the cream of the crop off the top. However not everyone here has the experience and background to highlight the important aspects of different JVMs. So what I would suggest is that you both start a list either in Wiki or in subversion that highlights these areas and where they are implemented and the papers in which they described etc. This will make it much easier for other people to make an informed decision. That's a good idea... I've made a small start.. http://wiki.apache.org/harmony/JVM_Implementation_Ideas -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
[Harmony Wiki] Update of People by RafalLewczuk
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by RafalLewczuk: http://wiki.apache.org/harmony/People -- || Raffaele Castagno || raffaele.castagno AT gmail.com || Available for translation to Italian of Harmony docs || || Panagiotis Astithas || past AT ebs.gr || ??? || || Mladen Turk || mturk AT apache.org || Httpd/APR/Tomcat/Commons || Yes || + || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk || not yet ||
[Harmony Wiki] Update of People by RafalLewczuk
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by RafalLewczuk: http://wiki.apache.org/harmony/People -- || Raffaele Castagno || raffaele.castagno AT gmail.com || Available for translation to Italian of Harmony docs || || Panagiotis Astithas || past AT ebs.gr || ??? || || Mladen Turk || mturk AT apache.org || Httpd/APR/Tomcat/Commons || Yes || - || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk || not yet || + || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk, minix / amoeba kernels (academic) || not yet || || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe, LSID ||
[Harmony Wiki] Update of People by RaffaeleCastagno
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by RaffaeleCastagno: http://wiki.apache.org/harmony/People -- || Ozgur Akan || akan AT aiqa.com || www.projectme.org || || Juan Leyva || familialeyva AT yahoo.es || small projects,patches || || Tony McCrary || [EMAIL PROTECTED] || ??? || Yes || - || Raffaele Castagno || raffaele.castagno AT gmail.com || Available for translation to Italian of Harmony docs || + || Raffaele Castagno || raffaele.castagno AT gmail.com || Available for translation to Italian of Harmony docs || not yet || || Panagiotis Astithas || past AT ebs.gr || ??? || || Mladen Turk || mturk AT apache.org || Httpd/APR/Tomcat/Commons || Yes || || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk, minix / amoeba kernels (academic) || not yet ||
[Harmony Wiki] Update of People by pady
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by pady: http://wiki.apache.org/harmony/People -- || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk, minix / amoeba kernels (academic) || not yet || || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe, LSID || || Craig Blake || craigwblake AT mac.com || || Yes || + || pady srini || pady.srinivasan AT fidelity.com || Java programmer/architect || Yes ||
RE: [Harmony Wiki] Update of People by NicolasCannasse
Can these either be turned off or sent to another list? They seem to generate a lot of email that isn't related to the topic at hand. Thanks, dan Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by NicolasCannasse: http://wiki.apache.org/harmony/People -- || Mark Wielaard || mark AT klomp.org || GNU Classpath || || Jonathan Worthington || jonathan AT jwcs.net || [http://www.parrotcode.org/ Parrot] || || Robin Garner || robin.garner AT anu.edu.au || [http://jikes.sourceforge.net/ JikesRVM] || - || Nicolas Cannasse || ncannasse AT motion-twin.com || [http://ncannasse.free.fr MotionTypes VM] || + || Nicolas Cannasse || ncannasse AT motion-twin.com || [http://ncannasse.free.fr MotionTypes VM] || Not yet || == All others with Open source experience if any (Alphabetical) == || Name || Email || Open source project || Interested in becoming a Committer? ||
[Harmony Wiki] Update of People by pady
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by pady: http://wiki.apache.org/harmony/People -- || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk, minix / amoeba kernels (academic) || not yet || || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe, LSID || || Craig Blake || craigwblake AT mac.com || || Yes || - || pady srini || pady.srinivasan AT fidelity.com || Java programmer/architect || Yes || + || pady srini || pady.srinivasan AT fidelity.com || Java programmer/architect, small projects/patches || Yes ||
Re: [Harmony Wiki] Update of People by RobGonzalez
--- Apache Wiki [EMAIL PROTECTED] wrote: + || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe, LSID || Kaffe?--Rob, shouldn't you be under Folks with prior VM Experience then? -Matt __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
[Harmony Wiki] Update of People by RobGonzalez
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by RobGonzalez: http://wiki.apache.org/harmony/People The comment on the change is: moved myself to people wth prior VM experience. -- || Jonathan Worthington || jonathan AT jwcs.net || [http://www.parrotcode.org/ Parrot] || || Robin Garner || robin.garner AT anu.edu.au || [http://jikes.sourceforge.net/ JikesRVM] || || Nicolas Cannasse || ncannasse AT motion-twin.com || [http://ncannasse.free.fr MotionTypes VM] || Not yet || + || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe || == All others with Open source experience if any (Alphabetical) == || Name || Email || Open source project || Interested in becoming a Committer? || @@ -49, +50 @@ || Panagiotis Astithas || past AT ebs.gr || ??? || || Mladen Turk || mturk AT apache.org || Httpd/APR/Tomcat/Commons || Yes || || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk, minix / amoeba kernels (academic) || not yet || - || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe, LSID || || Craig Blake || craigwblake AT mac.com || || Yes || || pady srini || pady.srinivasan AT fidelity.com || Java programmer/architect, small projects/patches || Yes ||
Re: [Harmony Wiki] Update of People by RobGonzalez
--- Rob Gonzalez [EMAIL PROTECTED] wrote: good point, though i feel a bit outgunned by the other guys in that list :) dalibor, mark wielaard, tom tromey...big guns in free java. i just hacked on kaffe for a while, did some debugging, build most of a verifier, hacked on it as part of one of those proposals to add generics to java sort of thing. I suppose it's your call, but considering that others of us have zero VM experience, the above sounds like quite a bit to e.g.: me. -Matt __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Re: [Harmony Wiki] Update of People by RobGonzalez
Rob, Please move it...any experience is better than none :) -- dims On 5/24/05, Rob Gonzalez [EMAIL PROTECTED] wrote: good point, though i feel a bit outgunned by the other guys in that list :) dalibor, mark wielaard, tom tromey...big guns in free java. i just hacked on kaffe for a while, did some debugging, build most of a verifier, hacked on it as part of one of those proposals to add generics to java sort of thing. -Rob On 5/24/05, Matt Benson [EMAIL PROTECTED] wrote: --- Apache Wiki [EMAIL PROTECTED] wrote: + || Rob Gonzalez || rob.gonzalez AT gmail.com || Kaffe, LSID || Kaffe?--Rob, shouldn't you be under Folks with prior VM Experience then? -Matt __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html -- Davanum Srinivas - http://webservices.apache.org/~dims/
[Harmony Wiki] Update of JVM Implementation Ideas by RodrigoKumpera
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by RodrigoKumpera: http://wiki.apache.org/harmony/JVM_Implementation_Ideas -- * Idea: let objects' primitive fields grow upward from the object head and let reference fields grow downward from the object head. Object pointers pointing to objects themselves containing object references therefore point into the middle of the object's memory area. * Advantages: all object references are contiguous, which makes following these references during garbage collection, etc. easier and simpler. - * Disadvantages: object head (lockword, vtable pointer, etc) is not necessarily at the beginning of an object's memory area, which can mean extra work to find the head when iterating through the heap e.g. during mark/sweep GC. + * Disadvantages: object head (lockword, vtable pointer, etc) is not necessarily at the beginning of an object's memory area, which can mean extra work to find the head when iterating through the heap e.g. during mark/sweep GC. Etiene notes that there is a performance degradation, mainly due to poor locality of this layout. * Origin: SableVM === Spinless thin-locks === @@ -37, +37 @@ * Idea: threads must periodically check whether they need to do something. Typically this is done at backward branches. To make this check efficient, have the thread read a byte from a well-known page of mmap()'d memory. When another thread wants the thread to check-in, it simply maps that page unreadable. The target thread gets a signal, it does whatever check required, the page is re-mapped readable, and the target thread returns from the signal and continues on its merry way. * Advantages: efficient way to enforce checking in - * Disadvantages: requires mmap() and signals + * Disadvantages: requires mmap() and signals, signal latency can be an issue if the notification delay is critical, eg gc safepoints (see the paper from some Sun guys about this) * Origin: unknown/multiple; implemented in lots of places. + + === Inline threaded interpreter === + + * Idea: similar to a direct threaded interpreter, but in the preparation step copy the code segment of some opcodes instead of pointer + data. + * Adavantages: faster interpreter. + * Disavantages: deciding with code segments can be inlined is a non-trivial, non-portable issue. A conservative aproach will result in worse performance. + * Origin: SableVM +
[Harmony Wiki] Update of DaneseCooper by DaneseCooper
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by DaneseCooper: http://wiki.apache.org/harmony/DaneseCooper -- #language en == Danese Cooper == - Adresse électronique : [[MailTo(danese AT gmail DOT com)]] + Email : [[MailTo(danese AT gmail DOT com)]] - ... + Formerly employed at Sun, now at Intel...long time advocate for open source Java and original listed supporter of Harmony. + + Serves on the board of the Open Source Initiative (http://www.opensource.org). + + Blog at http://danesecooper.blogs.com/divablog. + + Co-editor of new book, ''Open Sources 2.0'', published by O'Reilly 2005 CategoryHomepage
[Harmony Wiki] Update of People by DaliborTopic
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by DaliborTopic: http://wiki.apache.org/harmony/People The comment on the change is: added contact details for dalibor topic -- || Ricardo Morin || ??? || ??? || || Georges Saab || ??? || ??? || || Bruno Souza || ??? || ??? || - || Dalibor Topic || ??? || Kaffe || + || Dalibor Topic || robilad AT kaffe.org || [http://www.kaffe.org Kaffe] || Yes || || Tom Tromey || ??? || GCJ || || Weldon Washburn || weldonwjw AT gmail.com || ??? || || Mark Wielaard || mark AT klomp.org || GNU Classpath ||
Re: [Harmony Wiki] Update of People by NicolasCannasse
We'll switch to the -commits list. We want the general developer community to be watching this stream also. Thanks for the patience... geir On May 24, 2005, at 12:29 PM, Craig Blake wrote: Yeah, please. Not sure if these are really valuable anyways. Thanks, Craig On May 24, 2005, at 8:33 AM, dan sinclair wrote: Can these either be turned off or sent to another list? They seem to generate a lot of email that isn't related to the topic at hand. Thanks, dan Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by NicolasCannasse: http://wiki.apache.org/harmony/People -- || Mark Wielaard || mark AT klomp.org || GNU Classpath || || Jonathan Worthington || jonathan AT jwcs.net || [http:// www.parrotcode.org/ Parrot] || || Robin Garner || robin.garner AT anu.edu.au || [http:// jikes.sourceforge.net/ JikesRVM] || - || Nicolas Cannasse || ncannasse AT motion-twin.com || [http:// ncannasse.free.fr MotionTypes VM] || + || Nicolas Cannasse || ncannasse AT motion-twin.com || [http:// ncannasse.free.fr MotionTypes VM] || Not yet || == All others with Open source experience if any (Alphabetical) == || Name || Email || Open source project || Interested in becoming a Committer? || -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[Harmony Wiki] Update of DaliborTopic by DaliborTopic
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by DaliborTopic: http://wiki.apache.org/harmony/DaliborTopic New page: One of the current generation of the Kaffe developers. Loud, clear, Free Software person. Enjoys implementing runtimes for fun from spare parts, and integrating those parts into a coherent whole. Has a healthy anti-NIH attitude. which he developed during co-maintaining [http://www.kaffe.org Kaffe] for the last few years. Has merged almost anything worth merging on the class library side into Kaffe, and is now moving to merge VM components and good work done in the various forks of Kaffe on isolation, single system image, jits, embedded and realtime solutions into the main Kaffe.org tree, harmonizing the Kaffe world. Blogs about the state of affairs ocassionally on [http://planet.classpath.org Planet Classpath], but prefers to get things done, rather than talk lofty about them. Regards non-free software licenses as source of involuntary tragicomical entertainment.
Re: [Harmony Wiki] Update of People by NicolasCannasse
Heh, well, depends on the particular one I suppose. :-) I don't know that it's important to be notified of each new interested party. I imagine we will get many thousands of them (ok, maybe not, but we can hope anyways). Maybe having separate messages for edits is overkill. Is there some way to have it post summaries or a digest at reasonable intervals instead? Craig On May 24, 2005, at 9:38 AM, Matt Benson wrote: --- Craig Blake [EMAIL PROTECTED] wrote: Yeah, please. Not sure if these are really valuable anyways. What, People? :) -Matt Thanks, Craig On May 24, 2005, at 8:33 AM, dan sinclair wrote: Can these either be turned off or sent to another list? They seem to generate a lot of email that isn't related to the topic at hand. Thanks, dan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Harmony Wiki] Update of RobGonzalez by RobGonzalez
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by RobGonzalez: http://wiki.apache.org/harmony/RobGonzalez New page: I hacked on Kaffe for a while as part of my undergraduate thesis, which explored how modifications to the JVM's classloader and bytecode verifier could allow for a more expressive source language (specifically LOOJ, an extension of Java that adds parametric polymorphism as well as the notions of ThisType, ThisClass, and exact types to Java). The modifications would also allow the JVM to be more easily targeted by a wider range or source language (e.g. ML cannot really target the current JVM spec very well because of the constraints of the JVM's static type system). I wrote most of a bytecode verifier for Kaffe--enough to test the modifications proposed in my thesis--but never completed it (e.g. it was a little buggy and didn't adequately deal with the asinine bytecode subroutine instruction, JSR). TomTromey wrote a complete verifier for GCJ that we were planning a merging into Kaffe as a replacement. I currently work for IBM's Internet Technology Group in Cambridge and hope to hack on Harmony as much as I'm able to on the side.
Re: [Harmony Wiki] Trivial Update of People by RickyClarkson
How to unsubscribe from wiki changes update ? I've already checked by subscription list in the wiki, it's empty. cheers, Art
Re: Sun lashes out at open source J2SE
[Original Message] From: Mladen Turk [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 5/24/05 5:41:28 AM Subject: Re: Sun lashes out at open source J2SE Geir Magnusson Jr. wrote: Eh. Lets just keep to our purpose and message of compatibility and openness. When we move from 'enthusiasm' to the 'project' more and more 'doubts' will be seen :) As we move along, we _must_ remember the little ditty attributed to Henry Ford: Success is going from one failure to the next without loss of enthusiasm. Let's remember that we are at this point an assemblage of disparate but interested professionals. We don't have to get _everything_ right the first time, but we do need to build a community of the interested. Notice a regular theme in this list being to build community first, tinker in the sandbox second, and build something third, (goto step 2 until finished, and reinforce step 1 where necessary). We're gonna get things WRONG from time to time, but if we're a community, we'll get errors corrected and build it RIGHT. In all our enthusiasm, in all our doubts, let's be patient while we are jumping in to our next failure, because eventually WE WILL SUCCEED if we keep at it Just thought y'all needed that! Let's just play our song and let others have all the doubts they wish. Regards, Mladen. Dan Lydick
Re: [Harmony Wiki] Trivial Update of People by RickyClarkson
Art - Arthit Suriyawongkul wrote: How to unsubscribe from wiki changes update ? I've already checked by subscription list in the wiki, it's empty. When a separate mailing list has been set up for wiki changes, the changes will go there, and you'll be able to (un)subscribe to that list however you wish. Regards, Upayavira
Re: [Harmony Wiki] Trivial Update of People by RickyClarkson
On 5/24/05, Upayavira [EMAIL PROTECTED] wrote: When a separate mailing list has been set up for wiki changes, the changes will go there, and you'll be able to (un)subscribe to that list however you wish. Thank you. Art
Re: Sun lashes out at open source J2SE
Well said. Failure is easy to predict, and any average person can do it. It is more virtuous to fail having tried, than to succeed in predicting failure. Therein lies the difference between average people, and exceptional people. Clinton Begin http://www.ibatis.com On 5/24/05, Dan Lydick [EMAIL PROTECTED] wrote: [Original Message] From: Mladen Turk [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 5/24/05 5:41:28 AM Subject: Re: Sun lashes out at open source J2SE Geir Magnusson Jr. wrote: Eh. Lets just keep to our purpose and message of compatibility and openness. When we move from 'enthusiasm' to the 'project' more and more 'doubts' will be seen :) As we move along, we _must_ remember the little ditty attributed to Henry Ford: Success is going from one failure to the next without loss of enthusiasm. Let's remember that we are at this point an assemblage of disparate but interested professionals. We don't have to get _everything_ right the first time, but we do need to build a community of the interested. Notice a regular theme in this list being to build community first, tinker in the sandbox second, and build something third, (goto step 2 until finished, and reinforce step 1 where necessary). We're gonna get things WRONG from time to time, but if we're a community, we'll get errors corrected and build it RIGHT. In all our enthusiasm, in all our doubts, let's be patient while we are jumping in to our next failure, because eventually WE WILL SUCCEED if we keep at it Just thought y'all needed that! Let's just play our song and let others have all the doubts they wish. Regards, Mladen. Dan Lydick
[Harmony Wiki] Update of People by BlakeCrawford
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by BlakeCrawford: http://wiki.apache.org/harmony/People -- || Craig Blake || craigwblake AT mac.com || || Yes || || pady srini || pady.srinivasan AT fidelity.com || Java programmer/architect, small projects/patches || Yes || || Ulrich Kunitz || kune AT deine-taler.de || patches/Mono class library/my own unfinished toy VM || Yes || + || Blake Crawford || blake AT blakecrawford.com || cucina(coming soon),java technical lead || not yet ||
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Archie Cobbs wrote: That's a good idea... I've made a small start.. http://wiki.apache.org/harmony/JVM_Implementation_Ideas Excellent! --Steve
[Harmony Wiki] Trivial Update of People by IanDarwin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by IanDarwin: http://wiki.apache.org/harmony/People -- || SimonChappell || simonpeterchappell AT gmail.com || Java programmer and Technical Lead || || Ricky Clarkson || ricky_clarkson AT yahoo.com || Some patches, lots of talk! || Contributor || || DaneseCooper || danese AT gmail dot com || community/OSI || - || [:IanDarwin:Ian Darwin] || ian62 AT darwinsys.com || Tomcat/OpenBSD/etc || + || [:IanDarwin:Ian Darwin] || ian62 AT darwinsys.com || Tomcat/OpenBSD/etc || Yes || || Agustí Dosaiguas || agusti AT dosaiguas.net || || Yes || || Ben Laurie || ben AT algroup.co.uk || httpd/security || || Rafal Lewczuk || rafal.lewczuk AT gmail.com || netatalk, minix / amoeba kernels (academic) || not yet ||
Re: [Harmony Wiki] Trivial Update of People by IanDarwin -- STOP
Please harmony-dev: Stop Stop Stop sending me these notices! Stop Stop -- Dan Cohen in Calgary -- On Tuesday 24 May 2005 15:26, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by IanDarwin: http://wiki.apache.org/harmony/People ...
Re: [Harmony Wiki] Trivial Update of People by IanDarwin -- STOP
DONE :) On 5/24/05, Dan Cohen [EMAIL PROTECTED] wrote: Please harmony-dev: Stop Stop Stop sending me these notices! Stop Stop -- Dan Cohen in Calgary -- On Tuesday 24 May 2005 15:26, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Harmony Wiki for change notification. The following page has been changed by IanDarwin: http://wiki.apache.org/harmony/People ... -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Terminology etc
Steve, this clarification of terminology helped me a lot to understand your approach better. As Java-in-C camper I can even see now the advantages in the approach. But just let me add my 2 cents of pretty wild ideas. Having read your MMTk papers, it appears to me that the required JAVA extensions look a little bit like parts of P/Invoke* of Microsoft's Common Language Runtime. (P/Invoke is a convenient way to call C functions in the VM without the need to program glue code in C. It must allow memory access over pointers via a Marshal class. Security fanatics should recognize, that such a class can be implemented for Java using JNI.) A comparable mechanism in Harmony would not only be useful for the Java garbage collector but also the OS interface. Maybe it would be possible to extend the boot image approach to some kind of cached images of Java classes and packages, This would require some ELF-like format for compiled Java code. Such a feature might reduce the startup times of applications like Eclipse a lot. If I'm not misinformed the gcj developers want to build something like this. IMHO a self-hosting VM has the advantage, that performance is under your own control. Code in C will always depend on the optimizations provided by the C compiler being used. Additionally all the debugging/profiling/management code can be written in Java and can use the large Java class library. The class library itself provides also the platform abstractions, which will be needed to support Windows and POSIX platforms with the same code. But it might still be that C-implemented modules (particularly the GC) are faster than their Java-implemented counterparts, because they ignore array-index-checking, don't need write barriers and interface calls, etc... One could follow the strategy, that modules must support Java interfaces but might be implemented in C. This strategy would bring us back to an design that doesn't mandate which language has to be used to implement a certain module. Uli
Re: Terminology etc
I think you dind't quite get how it works with MMtk. There are a few magic classes that receive special treatment from the compiler and translates method calls into pointer operations. This way MMtk can operate under the same condition of C code. I'm not sure how did you relate interface calls with MMtk, as this is a non-issue. And with memory barriers, it's a problem all languages will have to face, be it Java, C or assembly. But it might still be that C-implemented modules (particularly the GC) are faster than their Java-implemented counterparts, because they ignore array-index-checking, don't need write barriers and interface calls, etc... One could follow the strategy, that modules must support Java interfaces but might be implemented in C. This strategy would bring us back to an design that doesn't mandate which language has to be used to implement a certain module. Uli
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Weldon Washburn wrote: In response to Geir's request, below is a first cut at a simple high-level modular structure: 1.1) Execution Modules Execution Manager Execution Engine Code generator Profile Collector 1.2) GC 1.3) Threading/sync Manager 1.4) Platform Portability Layer (OS and HW) 1.5) Class Libraries 1.6) Platform Accessors 1.7) VM Accessors 1.8) VM Core (the hub that glues all the above modules together) Others I can think of... :-) - JNI native interface module - JNI invocation interface module - Global/local references manager - Reflection manager (i.e., used by reflection native code) - Invocation manager - required to dynamically invoke methods from within the VM itself - Exception manager - can unwind stacks to throw exceptions - Bootstrapper - code to get the VM started - Resolver - performs field, class, method resolution - Verifier - Class initializer - invokes clinit's - Boot loader - the bootstrap class loader (reads ZIP files, etc) - Class deriver - defines runtime types (including array types) - Native library manager - dlopen()'s native libs, finds functions - Properties manager - sets system properties (e.g., java.vm.name). - String manager - converts between String - char *utf8; interning - Memory allocator - allocator for non-Java-heap memory - Finalizer module -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [arch] The Third Way : C/C++ and Java and lets go forward
updated wiki with this list - http://wiki.apache.org/harmony/HarmonyArchitecture On 5/24/05, Weldon Washburn [EMAIL PROTECTED] wrote: On 5/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 23, 2005, at 8:23 PM, Steve Blackburn wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. I sort of agree. It's clear we need more clarity about modularization (hint, hint) and that we need to be going on that (hint, hint), but I would be dollars to donuts that you could frame out a simple high level modular structure that we could start In response to Geir's request, below is a first cut at a simple high-level modular structure: 1.1) Execution Modules Execution Manager Execution Engine Code generator Profile Collector 1.2) GC 1.3) Threading/sync Manager 1.4) Platform Portability Layer (OS and HW) 1.5) Class Libraries 1.6) Platform Accessors 1.7) VM Accessors 1.8) VM Core (the hub that glues all the above modules together) How about starting a new thread titled [Modules Interfaces] to discuss a) the definition of the JVM's modules and b) what the interface APIs look like? -- Weldon refactoring a donated core from the beginning to start playing. I want to see people get their hands on showing how a VM core can be comprised of Java and C++. Also, I would bet that you could give us a laundry list of core kernel intrinsic APIs that we'd need to develop/refactor/import/etc for the Java pieces of the VM. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is not the case Geir. When a VM is built in Java, the only need for C/C++ is for direct interaction with the OS (one modest file of C code with interfaces to the most basic OS functionality), and for bootstrapping (another OS-specific file of C code plus about a dozen of lines of assembler). That's it. The kernel of the VM can be entirely written in Java. Whether or not we chose to do that is another matter, but your comment above is technically incorrect, and therefore should not be the basis on which we start coding. Maybe we're just having a semantic problem - I would consider the bootstrap part and the OS interaction part the kernel, and probably some non-OS pieces like helping out w/ memory management - letting the java work with raw pointers. There may be other pieces that you consider kernel that are in Java, and I'm fine with that. Please, just tell us what they are. This misconception highlights why it is that I think we need a seeding process to gain some collective understanding before we start cutting code for a new VM core. This requires some patience but I think will make the difference between us producing a) something that is free, runs OK, and is portable, from b) something that leverages the outstanding collective pool of ideas at the table (ovm, gcj, kaffe, joeq, jamvm, jc, orp, mudgevm, jikesrvm, etc etc) to deliver what I think could be the best performing, most exciting VM, free or non-free. define free. It has many meanings around here ;) Yes, this is just the seeding process given a kick. You want to show up with JikesRVM for the core functionality, I will do everything I can to help you get the paperwork done. But will need the direct interaction code, and the bootstraping code, and starting w/ a small existing project to help us on our way is all I was doing. I am very excited about all of the technology that this project is bringing out. I think JamVM looks outstanding, but I think it would be a serious error to take it as the core for Harmony. That wasn't the intention, in that it's not the core as a VM, but core as the kernel that we need for the modules, which may or may not be in Java. I understand that there will be parts that will be best done in Java - I'm all for it. It was not *designed* with our goals in mind. We need to understand where the value in JamVM (and all other candidates) is, and then maximize our leverage on that in the Harmony VM, whether it be through an entire VM (unlikely), components (I hope so), designs (I am sure), or mechanisms (certainly). I understand that it is important that we seize the enthusiasm of the list and start working, but respectfully, I think that cutting code for a VM kernel right now would be a bad mistake, one that might be gratifying in the short term but that is likely to lay the wrong foundation for what I think may become the most exciting VM project yet. We're not
Re: Terminology etc
Steve, if the spokes were in Java but the hub in C, would we then lose all of the aggressive inlining benefits that Java-in-Java solution can provide? I don't know. These are really interesting questions and ones I think we need to hear lots of informed opinion on. My experience with mixing C Java inside the VM is limited to the interface to the MM. The inlining issue is key there because of the fine grain at which those interactions occur. Scheduling, compilation and classloading are very much coarser grained, so those issues are much less critical there... To me the biggest challenge in mixing Java and C in a VM is the heap management issue. I can see several approaches, none of which are particularly palatable to me: a) C code uses its own heap (malloc), and regards the Java heap as read-only, and locks out the GC while it reads Java data. b) Use conservative GC for vm-internal data c) C code disables GC, and guarantees only to leave valid java objects on the Java heap. For example, suppose the classloader is written in Java, and leaves bytecode objects on the Java heap. Then you have an opt compiler written in C, which needs to access them. Using (a), you disable GC, malloc some heap for a copy of the bytecode, then re-enable GC. Then the compiler runs, produces some machine code, disables GC and copies it back to the Java heap. Then cleans up its own intermediate data structures ... It sounds like unnecessay complexity to me. Robin
vmmagic
Perhaps it is worth saying a little more about vmmagic. The basic idea is to provide the necessary extensions to Java for the construction of a java-in-java virtual machine. These fall into two categories: pragmas (some for safety, some for performance) and unboxed types. In all cases, these are regular java expressions that are noticed by the compiler as being special, intercepted and compiled to reflect the defined semantics of vmmagic. Thus, for example, when the compiler sees an instance of Address.loadInt(), it compiles it into a load instruction. Aside from satisfying the need to directly access memory, these types are used to enforce type safety, provide us with unsigned word type and abstract over issues such as the size of an address (32/64). The latter is extremely valuable in Jikes RVM where we support both 32 64 bit architectures. I've written a few notes about the history of vmmagic below, but I want to say right now that vmmagic has evolved and will continue to evolve, particularly in light of new developments such as annotations etc in J2SE 5. Pragmas. http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/package-summary.html The magic pragmas can in principle be scoped at least three ways. Per-class (overloading the implements keyword), per-method (overloading the throws keyword), and intra-method (overloading the try catch keywords). Presently we only use the first two. An example of a performance related pragma is InlinePragma, which is used to indicate that a method should always be inlined by the optimizing compiler. http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/InlinePragma.html An example of a correctness related pragma is UninterruptiblePragma which ensures that the compiler does not allow a method to be interrupted for thread switching (by omitting yield points). http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/UninterruptiblePragma.html Unboxed Types. http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html The Address type is used to provide raw memory access through its loadtype() and storetype() methods. It also provides a memory barrier abstraction with a prepare()/attempt() idiom. Finally, it abstracts over address width (32/64). Despite the appearance of a value field in the javadoc below, in fact the type is materialized by the compiler as a primitive 32/64 bit type, not an object, and its methods are reduced to the appropriate instructions (load, store etc), not method calls. http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/Address.html The ObjectReference type is used to provide an abstraction over object identifiers (rather than using Address, which is somewhat like using void*). In the case of Jikes RVM ObjectReferences are materialized as 32/64 bit primitive types with direct operations, with the toAddress() operator returning that same value (since Jikes RVM uses addresses as object identifiers). However in a VM that used handles, an ObjectReference would map to a handle and toAddress() would dereference the handle. http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/ObjectReference.html For more information I suggest you browse the java doc, and if brave, venture into the Jikes RVM compilers and see how the magic is actually implemented! Brief history The use of magic dates back to the beginning of the Jikes RVM project (then known as Jalapeno). I know of three major sources of refinement. First the OVM group, and in particular Chapman Flack (Purdue), made significant improvements to the Jalapeno approach to magic. Perry Cheng (IBM Research) then wrote an initial version of the Address, Word and Extent classes and in doing so with Kris Venstermans (Ghent) and Dave Grove (IBM Research) was able to identify and fix all of the thousands of uses of int (for address) in the Jikes RVM codebase. This was key to getting a 64 bit port going. Daniel Frampton (ANU) was responsible for packaging it as org.vmmagic, separating the unboxed and pragma types, and introducing new types including ObjectReference. Most of the original pragma types were written by Stephen Fink and Dave Grove (IBM Research). Cheers, --Steve
