Robin, My comments interspersed with your inquiry.
> -----Original Message----- > From: Robin Garner <[EMAIL PROTECTED]> > Sent: Oct 17, 2005 7:05 PM > To: Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> > Subject: Bootstrap JVM > > Hi Dan, > > I've had a quick look at the code for the bootstrap JVM, and I have a few > questions. > > Looking at the interface defined for the garbage collector, I have a great > difficulty understanding where you're coming from - a bunch of the > interface functions don't make sense to me, and there's other stuff that > seems to be missing. > --- That is correct. Notice I will soon be commiting the changes for a 0.0.1 release. My 0.0.2 release will contain the remaining work on the virtual opcodes and the code base will be ready for a true shared development effort, as you may have gathered from my other posts this week. --- > My understanding is that you haven't implemented a garbage collector - > just the stubs - is that right ? I think it should take a day or so for > me to write a simple semispace collector, which I think would be a useful > exercise. I don't promise to implement finalization and reference types, > though :) > > Do you have a brief description on how the interface is expected to work ? > This would be a big help. --- The docs will be in the 'docs/html/index.html' file for the main page. Near the beginning of that page is a description of each item on the menu bar, which contains an item named 'File List'. Click on 'File List' to find a list of all source files. Take a look at the documentation page for 'jvm/src/gc.h' or 'jvm/src/gc_stub.c'. You will find the API hooks described there as to how it works-- that is, how the _interface_ works. I basically call a GC function any tiime that I update either the class table or the object table, that is CLASS(clsidx) or OBJECT(objidx). This happens when I load or unload a class, a class static reference or array variable, or an object instance reference or array variable. The implementation is up to you. Have you run the configuration script 'config.sh' yet? If not, just wait a bit and I will have my 0.0.1 stuff available, which should have, among other things, a better distribution mechanism with a source and a source-plus-docs (preformatted) .tar.gz file. Notice that in 'config.sh' I have a "roll your own" selection for both heap allocation and for garbage collection. Look at 'jvm/src/heap.h' and at 'config.sh' for details on how I set up a configuration for compile time for one heap allocation algoritm or another. I have implemented two heap management algoritms with can be used as a starting point on how to implement compile-time configuration for a "roll your own" GC algorithm. I'd be glad for your contribution toward the first meaningful GC. --- > I couldn't seem to find where in the VM the object model is defined - > could you give me some hints ? Ditto, the place where GC maps are > generated. --- The object model is found in 'jvm/src/object.[ch]', and the related class model is in 'jvm/src/class.[ch]'. The GC maps are not implemented since there is only a stub found in 'jvm/src/gc_stub.c'. They would be set up by the function referenced by the GC_INIT() macro, which in the stub implementation points to 'gc_init_stub()'. For your 'xyz' implementation, it would point to 'gc_init_xyz()' instead. (See 'jvm/src/heap.h' for an example of what would be added to 'jvm/src/gc.h' to implement this.) --- > And lastly, just a comment. As far as I can see you've implemented > objects using handles that point off a big object table - is that correct > ? If so, it's one of the first things we need to fix before too much code > gets written - this kills performance. Objects need to point directly to > each other within the heap. Unless of course I've misunderstood and this > is just for the statics - in which case forget what I just said. > --- No, you are correct. This JVM is partly a pedagogical tool and partly a paradigmatic tool. It's meant to be modified in as many places as makes sense. I have tried to write the code in as modular a manner as possible for just this purpose. For example, the OBJECT() macro could be changed to reference any type of object table implementation, for example, a hash map, a linked list, anything else, and the object table 'robject object[]' declaration in the 'rjvm' declaration in 'jvm/src/jvm.h' would simply be changed to match that data structure. See the 'README' file for details on this subject in the paragraph named "Subsystem component abstraction." I don't remember whether or not this paragraph is in the 0.0.0 version, but it certainly is in my current pre-0.0.1 revision. (Look for it coming in soon on the harmony-commits@ list.) As far as performance goes, certain objects _do_ point to each other, and a change could be made in the existing 'robject' definition in 'jvm/src/object.[ch]' to reflect that in whatever ways would improve performance. There are two ways objects point to each other. First, the CLASS() table (the 'rclass' structure in 'jvm/src/class.h') has a 'jvm_object_hash' that points to an OBJECT() table entry containing the object information about the class. In the 'robject' structure in 'jvm/src/class.h', there is a jvm_class_index in the linkage table that points back to the CLASS() table entry. Furthermore, any reference type such as an array reference or any arbitrary object reference will be stored as object number X in the object table, namely OBJECT(X). The data type for X is 'jvm_object_hash', and you will find it all over the code. I am open to _whatever_ improvements make sense. The simple array implementation as 'pjvm->object[max_objects]' as a member of 'rjvm' was convenient starting mechanism. (Notice that this looks a lot like the definition of OBJECT(), as found in 'jvm/src/object.h.) --- > cheers, > Robin > > PS, I think it's particularly brave to implement a VM from scratch! As a > learning exercise, it's second to none, though, and while I expect this > codebase will be overtaken by events, I'm happy to help out to the small > extent that my time allows. --- Thanks for your encouragement! I was a bit hesitant at first, not knowing what people would say, but everyone has been most supportive in response to my contribution. Let's keep getting our heads together and produce a serious piece of art! Dan Lydick
