Re: VMInterface addition: Make native library names part ofVMInterface

[Patrik Reali]

----- Original Message -----
Tom Tromey writes:
> David> I don't think there is an easy solution to this as it is unlikely
> David> that a single VMInterface will fit the needs of all VMs perfectly.
> David> In some cases (java.lang.ref.* for example), I don't think that it
> David> is reasonable for classpath to try to provide an implementation
> David> that will actually work unchanged on all VMs.
>
> Andrew> Exactly.  Classpath should provide a reference implementation,
> Andrew> we but shouldn't expect every core class to be used unchanged.
>
> I agree.  I think it is reasonable to expect libgcj to diverge from
> classpath in some places -- there are areas where libgcj's needs
> aren't the same as the needs of other VMs.  But at the same time, I'd
> expect VMs that are unusual in other ways (e.g., IKVM or JikesRVM,
> both "different" in one way or another) to also occasionally have
> their own divergence.  Or, to put it another way, let's distribute
> some of the divergence; it can't all rest on libgcj.  (Which I doubt
> anyone is proposing anyway.)
>

I agree with you.

My approach is rather pragmatic: first, classpath should allow to quickly
develop a VM, by providing a clean design and as many features as possible
in Java.

Then, once the VM is running, everybody can choose the optimizations that
match the problem that the VM is trying to address. In practice, as soon as
one VM leaves the state of "pet project" or "proof of concept",
optimizations are unavoidable.

I'm not sure that compiler optimizations (in particular inlining and pointer
escape analysis) can handle every problem (and as I remember, they ofter
require static compilation and limit dynamic loading, a core java feature),
thus some code modification may be required to optimize the API for the VM.

Anyway, coming myself from the compiler world, you can imagine how painful
it is for me to say that native methods should forward the call to the VM*
classes (thus adding an indirection). This has for me the following
advantages:
* clear separation between the API and the VM
* regrouping the native methods into a few classes (it is simpler to find
out which methods must be implemented, and the number of stubs to create is
much smaller, which is less code to manage)

On the other hand, the VM* approach causes additional costs:
* often requires to duplicate structures to keep track of one information.
* additional indirection in each invocation

As often the case, good design and optimizations don't mix well! In case of
doubt, I always choose the good design (it fits every case) over the
optimization (it usually fits only a specific use-case).

But this is just my own opinion.

-Patrik
--------
Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos