Re: Fwd: [DRLVM] proposal to port MMTK to drlvm
On 6/14/06, Robin Garner [EMAIL PROTECTED] wrote: The port to rotor was done by Andrew Gray at ANU, and was based on my work integrating MMTk into C-based runtimes. The approach used was to apply a source code transformation to turn the MMTk 'magic' into native methods (using CNI) on primitive types, and compile MMTk with gcj. It is described in detail in my honours thesis. This confirms what I saw in the code. A bunch more pieces are falling into place. We will probably won't use GCJ or CNI. Instead, I am thinking of JITing MMTk at boot time just before calling GC init(). This will slow down boot but hopefully not make booting unbearable for developers. The hope is that it will be easy to put intrinsics into the JIT, jitrino.jet for all the classes in the unboxed package. Its sort of inlining but not in the traditional sense. The source transformer code is licensed as public domain, but would need considerable modification to work on the current MMTk code base. A far better approach would be to implement the vmmagic types in gcj. Or with a *.class to binary image compiler mentioned above. The bulk of the C code in the interface to Rotor is specific to rotor, and would need to be re-implemented for DRLVM anyway. Agreed. It might be nice to take a peek at the Rotor code to get ideas on how things could be implemented. The MMTk - VM interface is much cleaner these days: as Daniel points out, MM_Interface defines the JikesRVM - MMTk interface, and MMTk's interface to the vm is the package org.mmtk.vm. I am reading all the interface code now. I hope to have a general outline of the MMTk to drlvm port in a few days. I would be much appreciated if you can review it and tell me what to fix. MMTk is compiled to a JAR file against stubs for this package, and the directory ext/JikesRVM contains the JikesRVM-specific implementation of the interface. Its good to learn this. A first step will be to compile MMTk all by itself and put all of it in a JAR file. By the way, do you know how much effort it was to port MMTK to Rotor? Thanks for all the help. Weldon -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: [DRLVM] proposal to port MMTK to drlvm
Weldon Washburn wrote: oops, I forgot to cc: -- Forwarded message -- From: Weldon Washburn [EMAIL PROTECTED] Date: May 24, 2006 11:23 AM Subject: Re: [DRLVM] proposal to port MMTK to drlvm To: [EMAIL PROTECTED] On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote: that is cool, so the other thing i was thinking about is that MMTK is written for JikesRVM which is a meta-circular java implementation. AKA it is written in java with some magic for the low level mem stuff. I am not sure how that would integrate into Harmoney and the DRLVM. I dont think it would be hard to port it to another language or we could write some sort of interface to bridge the two. Not sure what are your ideas? hmm somewhere I heard that MMTK had been ported to Microsoft Rotor. I know Rotor is a vm written in C/C++. If this port is under an Apache agreeable license, then we could look at this code. If no MMTK-to-C interface that is compatible with Apache license exists then, of course, we will need to build one. My preference would be to keep it the interface combinations to C and Java. I would rather not bog down MMTK/HarmonyDRLVM with any C++ distractions initially. I think the initial focus is functionality, cleaning up the C interface, then performance. The port to rotor was done by Andrew Gray at ANU, and was based on my work integrating MMTk into C-based runtimes. The approach used was to apply a source code transformation to turn the MMTk 'magic' into native methods (using CNI) on primitive types, and compile MMTk with gcj. It is described in detail in my honours thesis. The source transformer code is licensed as public domain, but would need considerable modification to work on the current MMTk code base. A far better approach would be to implement the vmmagic types in gcj. The bulk of the C code in the interface to Rotor is specific to rotor, and would need to be re-implemented for DRLVM anyway. The MMTk - VM interface is much cleaner these days: as Daniel points out, MM_Interface defines the JikesRVM - MMTk interface, and MMTk's interface to the vm is the package org.mmtk.vm. MMTk is compiled to a JAR file against stubs for this package, and the directory ext/JikesRVM contains the JikesRVM-specific implementation of the interface. cheers - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [DRLVM] proposal to port MMTK to drlvm
oops. I forgot to cc: -- Forwarded message -- From: Weldon Washburn [EMAIL PROTECTED] Date: May 24, 2006 6:43 AM Subject: Re: [DRLVM] proposal to port MMTK to drlvm To: [EMAIL PROTECTED] Daniel, I really appreciate your offer to help. On the surface, our backgrounds are complementary. I know very little about MMTK. However, I know something about the Harmony project and the DRLVM that was donated to Harmony. I plan to download MMTK source code soon and take a look so that I can ask you intelligent questions. It would be great if you have the time to download Harmony DRLVM source and also have a look. Thanks Weldon On 5/23/06, Daniel Feinberg [EMAIL PROTECTED] wrote: I would like to help. I have experiance with MMTK as i did research with it for a long time in the DeCapo Group with Darko S. at UNM. Let me know what i can do. I dont have much experiance with Harmony but i dont know if that will matter. On 5/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: Folks, There were several interesting email chains about Harmony VM and MMTK last year. This topic died in large part because there was no JVM. Since then, several JVMs have been donated. I volunteer to do an initial investigation of porting MMTK to the recent DRLVM donation. From a quick grep of the code, it appears that write barriers are only partially implemented. We will need to make write barriers functional before many of the features of MMTK can be used. Thoughts? Weldon -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Feinberg http://www.cs.unm.edu/~danielf -- Weldon Washburn Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [DRLVM] proposal to port MMTK to drlvm
oops, I forgot to cc: -- Forwarded message -- From: Weldon Washburn [EMAIL PROTECTED] Date: May 24, 2006 11:23 AM Subject: Re: [DRLVM] proposal to port MMTK to drlvm To: [EMAIL PROTECTED] On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote: that is cool, so the other thing i was thinking about is that MMTK is written for JikesRVM which is a meta-circular java implementation. AKA it is written in java with some magic for the low level mem stuff. I am not sure how that would integrate into Harmoney and the DRLVM. I dont think it would be hard to port it to another language or we could write some sort of interface to bridge the two. Not sure what are your ideas? hmm somewhere I heard that MMTK had been ported to Microsoft Rotor. I know Rotor is a vm written in C/C++. If this port is under an Apache agreeable license, then we could look at this code. If no MMTK-to-C interface that is compatible with Apache license exists then, of course, we will need to build one. My preference would be to keep it the interface combinations to C and Java. I would rather not bog down MMTK/HarmonyDRLVM with any C++ distractions initially. I think the initial focus is functionality, cleaning up the C interface, then performance. On 5/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote: yes that would be fine. Do you use skype or another communication service. I don't have skype installed. However, if the phone call is around the US, I have cell phone and land line that don't have long distance fees. I will send phone numbers to you directly. That way we can talk about this kind of stuff. On 5/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: Daniel, I really appreciate your offer to help. On the surface, our backgrounds are complementary. I know very little about MMTK. However, I know something about the Harmony project and the DRLVM that was donated to Harmony. I plan to download MMTK source code soon and take a look so that I can ask you intelligent questions. It would be great if you have the time to download Harmony DRLVM source and also have a look. Thanks Weldon On 5/23/06, Daniel Feinberg [EMAIL PROTECTED] wrote: I would like to help. I have experiance with MMTK as i did research with it for a long time in the DeCapo Group with Darko S. at UNM. Let me know what i can do. I dont have much experiance with Harmony but i dont know if that will matter. On 5/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: Folks, There were several interesting email chains about Harmony VM and MMTK last year. This topic died in large part because there was no JVM. Since then, several JVMs have been donated. I volunteer to do an initial investigation of porting MMTK to the recent DRLVM donation. From a quick grep of the code, it appears that write barriers are only partially implemented. We will need to make write barriers functional before many of the features of MMTK can be used. Thoughts? Weldon -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Feinberg http://www.cs.unm.edu/~danielf -- Weldon Washburn Intel Middleware Products Division -- Daniel Feinberg http://www.cs.unm.edu/~danielf -- Weldon Washburn Intel Middleware Products Division -- Daniel Feinberg http://www.cs.unm.edu/~danielf -- Weldon Washburn Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [DRLVM] proposal to port MMTK to drlvm
-- Forwarded message -- From: Daniel Feinberg [EMAIL PROTECTED] Date: May 24, 2006 2:13 PM Subject: Re: [DRLVM] proposal to port MMTK to drlvm To: Weldon Washburn [EMAIL PROTECTED] Something like a reference counter does not really need a write barrier. They are mostly used when you are partitioning the heap into specific regions for objects that fit cirtian specifications. And again only if you are going to be collecting a region that has pointers that flow into the collected section of the heap. There might be other uses of write barriers. Another kind of collector that might be of interest that i dont believe is included in MMTK though it should be is the Older First collector which you can get the paper at the DaCapo website. Daniel On 5/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote: My understanding of write barriers is as an optimization. That fits with my understanding of write barriers also. I do not know for certain but suspect that MMTK can somehow be configured such that write barriers are not required for correctness. Maybe Dan Feinberg can tell the mailing list. So MMTK is a toolkit for building GCs. When doing generational collection the write barrier is used to keep track of pointers that go from older generations to yonger generations. You must have a way to track these objects because when you do a partial heap collection (aka just the nursery or nursery and old1) you need to build a root set of all things that point into that space. Then you trace this root set to find all live objects that need to be moved to an older generation. In other methods of collecting the write barrier is not as important. Thanks. This fits my expectations. One follow-up question. By not as important, do you mean functionally correct but bad performance or something else? Here unless you can find all of these pointers that point into a space from an older space you must use a write barrier. Daniel - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division -- Daniel Feinberg http://www.cs.unm.edu/~danielf -- Daniel Feinberg http://www.cs.unm.edu/~danielf - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [DRLVM] proposal to port MMTK to drlvm
-- Forwarded message -- From: Daniel Feinberg [EMAIL PROTECTED] Date: May 24, 2006 7:04 PM Subject: Re: [DRLVM] proposal to port MMTK to drlvm To: Ivan Volosyuk [EMAIL PROTECTED] This is good. The JikesRVM and MMTK code is also built like this with an interface between the two. You can find the code in: $RVM_ROOT/rvm/src/vm/memoryManagers/JMTk/vmInterface/ the file is: MM_Interface.java This file is the direct interface to the GC. This file and some others in that one directory are the only files left that are used from JMTk. (This i believe holds true in the newest versions but i have not worked with it in 1 year.) The rest are in the MMTk sub dir above the vm dir of the $RVM_ROOT directory. I dont know if this is helpful. On 5/24/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Agree. We have the GC interfaces declared in: vm/include/open/gc.h vm/include/open/vm_gc.h The interfaces hide implementation of VM, providing functionality to get root set in stop-the-world state, callbacks for object allocation and write barriers. Please, take a look at it. If you have questions, suggestions, extension feel free to ask. -- Ivan 2006/5/25, Daniel Feinberg [EMAIL PROTECTED]: So i have something to chime in with. Since this could be simple from the beginning and grow more complex as we develop it, we could start with an interface to the VM. This part is fairly isolated in the code. I think that as a starting point would be good. What does everybody else think? Daniel -- Daniel Feinberg http://www.cs.unm.edu/~danielf -- Daniel Feinberg http://www.cs.unm.edu/~danielf - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
