This is for Brian in particular, but I thought it would be useful to
everyone else.
Answers to questions about what I'm doing with Class and Runtime:
1. I moved Class, Thread, Constructor, Field, Method and Runtime out of
the main source tree and into vm/reference. There will be a vm/japhar and
vm/kaffe in the main tree unless another scheme I'm cooking up comes to
fruition (I'll let you know in a bit, let's finish integration and then
worry about build procedure).
2. vm/reference/* and vm/japhar/* and vm/kaffe/* : these are *classpath
roots*; they are not packages starting with vm.reference.*, vm.japhar.*, and
vm.kaffe.*. The original intention was to have a "template" you could work
off of in vm/reference, and then create VM-specific stuff in vm/japhar and
vm/kaffe and anything else.
3. All native methods for these six classes will be implemented by the
VM.
4. The rest are staying peers for now, because most of their methods are
pure Java and VM-independent. ClassLoader is the only one I can think of
that might switch to non-peer based on reason #3 below, but that's more an
aesthetic than practical decision. Object might switch based on reason #2
below, but I haven't seen anything that warrants that yet. For the others,
peer-ness matters
5. The way the classes will be provided: classpath.zip will have all
classes in it *except* VM-interface classes. There will be a separate JAR
or ZIP file for each VM containing the remaining classes. This gives
maximum portability and is the same scheme we were talking about before. I
just changed *which* classes are in each VM.
6. I *did* let everyone know about this and invited discussion a while
back, after I had been writing the interface for a while and came up against
these problems. No one responded, so I went ahead. I'm still willing to
change the interface, but not until *after* Japhar+Classpath integration is
working at the Hello World level. I've come too far to turn back right now
(very very close, I think).
7. The build of classpath, therefore, should use vm/reference as part of
its compiling classpath in order to work right. The resulting classes from
vm/reference should *not* be placed into classpath.zip, as that would be a
waste of space. If you wish, if it makes it easier, the classes from
vm/reference can be copied over to the main source tree, as long as you make
an exception and do not include files from there. *This is still true
whether or not I delegate to peers.*
Discussion about *why* I'm not delegating to peers in these classes:
1. Class, Thread, Constructor, Field and Method all have to associate
native data with instances. Some VMs would choose to do that by attaching a
particular member variable to the Class directly. If they did not control
the class, the only way to do it would be a hashtable like Paul's NSA.
Don't get me wrong, NSA is cool, but you're looking for absolute speed on
the native retrieval operation for these crucial classes--*especially* Class
and Thread. If an implementation can't be compiled for platforms above 64
bit anyway, what's to prevent them from using a long member variable to
store the pointer? And if Japhar gets a native data pointer per object in
there, it may well need a static "indicator variable" to tell Japhar that
that class *desires* the native data pointer, to save memory on the 98% of
classes that *don't* desire the native data pointer.
2. Runtime has nothing but native methods. It is very silly behavior to
delegate every single method in the class to a peer when the peer has no
"instance data" and does not have multiple children implementing the
interface. There are no programmatic benefits to it. I don't have a
problem switching this back, but it still seems silly to me.
3. The VM-specific classes could also do some optimizations for the
particular VM in stuff that I wrote as pure Java and did not delegate to a
peer. This is not as much of a plus, but something to consider.
4. There is the issue of the extra method call overhead incurred by
delegation, but a good VM could optimize it out. Remember, these methods
are called *often* in Java, especially Thread methods. They are the core of
the core. A little savings here gains a lot of speed overall.
One problem that could arise: if we seal java.lang in a classpath.jar, then
class loading errors will occur unless the VM makes a special sealing
exception for its own JAR. I don't like special exceptions.
--John Keiser
