Re: VMInterface addition: Make native library names part ofVMInterface

[Andrew Haley]

Mark Wielaard writes:
 > 
 > Hopefully we won't do it at the expense of elegance 'and' efficiency,
 > but I agree that sometimes it won't be possible to achieve both. As our
 > Hacker Guide puts it (even though it leaves out elegance):
 > 
 >         When you write code for Classpath, write with three things in
 >         mind, and in the following order: portability, robustness, and
 >         efficiency.
 >         
 >         If efficiency breaks portability or robustness, then don't do it
 >         the efficient way. If robustness breaks portability, then
 >         bye-bye robust code. Of course, as a programmer you would
 >         probably like to find sneaky ways to get around the issue so
 >         that your code can be all three ...

And clearly these guidelines are at odds with those of libgcj, where
(and this is just my opinion) we favour robustness, maintainability,
efficiency, portability.

My goal is to improve gcj's speed to the point where it matches all of
its competitors.  I will be very cross indeed if while I am improving
the compiler someone is concurrently pessimizing the library,

 > What I hoped was that by having the VMInterfaces classes clearly
 > marked as 'special', by being package local, final, having (mostly)
 > static methods, and starting the name with VM (*), would make it
 > easy for VMs and compilers to just inline all call to
 > them. Especially if you treat the Classpath core classes as
 > 'sealed' and compile them as complete packages. Maybe this is much
 > harder then I imagined.

It's not particularly difficult to do, but at the moment we don't do
it.  gcj is perfectly capable of whole-program Java optimization but
we have to follow Java rules, and one of those rules is that you
cannot inline final methods because it breaks binary compatibility.
We could teach gcj that VM<foo> classes are an exception to that rule,
but I think you would agree that's not a pretty solution.
Alternatively, we could perhaps have a compiler switch that allows
final methods to be inlined, so

   gcj -finline-final foo.class VMfoo.class

inlines all calls to final methods between foo and VMfoo.  However,
this would force us to rewrite the libgcj build scripts to handle
VMfoo classes in a special way.

However, none of this addresses Bryce's valid point that "too much
abstraction increases the complexity of the classes, making
maintenance more difficult."  I've worked on systems with too much
abstraction.  They are very hard to understand and debug.

Andrew.