Re: Bootstrap JVM

[Apache Harmony Bootstrap JVM <bo...@earthlink.net>]

Robin,

My comments interspersed with your inquiry.

> -----Original Message-----
> From: Robin Garner <ro...@anu.edu.au>
> Sent: Oct 17, 2005 7:05 PM
> To: Apache Harmony Bootstrap JVM <bo...@earthlink.net>
> 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