John Keiser wrote:
> The VM doesn't already implement Object--thus the need for VMObject, which
> implements the trivially few methods that actually require the VM's input.
> The point of the VM interfacewas to make the job as easy as possible for the
> VM to implement things (read: as few classes and methods as possible)
> without taking away their power to optimize and innovate.
But it is somewhat of a de-optimization since it adds a layer of indirection.
With your scheme, the Java implementation of Object's instance methods have to
delegate to a static native method.
> Controlling the
> structure of Object doesn't seem necessary for that power. If you have a
> need for control of the Java code for Object, let's talk. In my experience
> so far, it seems like you can put all the data you need into your internal
> native Object structure and thus don't even need a single Java field in
> Object.
It isn't that the VM needs control of the (trivial) Java code in Object. It's a
matter of simplicity and efficiency. Why not define native methods within
java.lang.Object that the VM is required to implement them with Classpath
supplying the implementation of the non-native methods ? This would eliminate
the indirection overhead.
-Scott
