> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Entire classes: java.lang.Class, java.lang.reflect.* (there are
> > specific optimizations a VM could make that would speed reflect up,
> > and Class is ... well, you know, it's Class!).
>
> We shouldn't leave out entire classes -- at the very least we should
> stub and document them. Parts of Class can be implemented in Java --
> for instance all the Resource dispatch calls to ClassLoader. We
> should be as VM independent as possible.
>
That's where "templates" come in. They are the documented stubs. The VMs
are expected to take the templates and modify the parts that are VM
specific.
> Do you really want to ditch your entire reflection implementation?
>
For the right reasons, I will. Most of the reflect stuff is doable in a
fairly VM-independent way, but there would be one or two crucial pieces that
the VM could implement. For example, the way I understand Japhar, instead
of going through the whole native state gig for Method, Field and
Constructor, it could store an int that references the
Method/Field/Constructor in the class. Since you can't do part of a class,
this necessitates their writing the entire file.
> > We write generic, well-commented skeletons for the VM-specific
> > things to make them easy to implement by a VM. Then the VM maker
> > writes the functions and gives us the modified c and h files and the
> > java files and we put them into a directory for that VM
> > (vm/japhar-1.1/java/lang, vm/japhar-1.1/java.lang, etc., etc.).
>
> I don't believe this is a good way to go about it. It would make more
> sense for the VM specific stuff to be shipped with the VMs. If we
> ship the VM specific stuff, then we might have to do a new release of
> Classpath anytime a new version of a VM is released.
>
Good point. It depends on whether the goal of Classpath is to produce an
implementation that is *compatible* with multiple VMs, or *binary
compatible* with multiple VMs. If we go the gnu.vm and VMI route, we can be
binary compatible. I think it is still possible without losing key
efficiency points. I don't think I'll scrap the template model, but I'll
modify it.
> Maybe a better idea would be to create a package called "gnu.vm" in
> the Classpath distribution. The package would consist of all the
> interfaces which a particular VM would need to implement in order to
> support Classpath.
>
I was thinking about it ... but some classes (java.lang.ClassLoader, Thread
and Runtime) especially have a bunch of methods that, if we created an
abstract interface to them, it would only be used once in all of Classpath.
You basically end up with an extra function call with no added benefit. For
example, Java__java_lang_Object_wait would call VMI_wait(). Our functions
basically become runtime wrappers. This will slow down the implementation
(extra unnecessary function call == extra unnecessary overhead).
I like gnu.vm, though ... that sounds like a better place to put
gnu.java.lang.StackFrame and ExecutionStack. Maybe even something called
SystemClassLoader? :)
> thoughts?
>
One possibility is to define a core subset of native methods the VM has to
define, that we assume are linked in when Classpath+VM runs. There would be
a VMI for other stuff, but this would help provide some of the necessary
base functionality. Then a compiled version of Classpath could still be
binary compatible with multiple VMs.
The only problems I see forthcoming are java.lang.Class and
java.lang.reflect.Method/Field/Constructor. We can provide a native_state
implementation for it, but in most VMs Method, Field and Constructor can use
a simple int to determine which method it is in the class. The same
argument could be made for java.lang.Class, for VMs that have an array of
classes. This means, however, that the VM would have to ultimately provide
the classfile in order to promote efficiency. The best way to do this is
templates.
--------------
A NEW PROPOSAL
--------------
Perhaps this is a better proposal:
Classpath will implement and doc-comment all classes, including everything
it possibly can from Class, Object, System, etc. It will leave out key
native methods from the binary distribution, which the VM is expected to
provide. For these methods, templates or "stubs" will be written, with
comments. It will also leave out java.lang.Class and
java.lang.reflect.Method, Field and Constructor. The VM is expected to
provide those as well. A complete, doc-commented template will be provided
for them, with comments suggesting where the VM should place its specific
optimizations.
This means that classes.zip is incomplete, however. I don't know whether
this is acceptable. But what I do know is that there are specific things
that can be done if the VM can implement certain classfiles, that will make
the whole implementation move significantly faster. A tool could be
provided to fold the VM classes into classes.zip, thus creating a
VM-specific classes.zip.
This means that a given Classpath distribution is *binary-compatible* with
any VM that chooses to implement those key native methods and those four key
classes.
Comments?
--John Keiser
