Re: VMInterface addition: Make native library names part ofVMInterface

[David P Grove]

I agree.

<disclaimer: I am not a lawyer....so
my grasp on the fine details of licensing is not to be trusted>

One issue that comes up for Jikes RVM
is that because we are licensed under the CPL we believe it is hard for
us to provide modified versions of classpath in a way that is easy for
our users to deal with.  Because of this we have taken a tact of either
(1) using a classpath class unchanged or (2) providing a complete replacement
for the class.  In most cases this is ok, but there are some cases
where we want/need to make a very small change to a classpath class and
things get awkward for us.  In many cases, this can be done by adding
a VMFoo class and a level of method calls.

For us, this introduces no overhead
because we inline them all away.  It seems to me that the key question
is can we construct this stuff in such a way that it causes no overhead
for gcj as well (is there some stylized cross class inlining that you can
do easily).  If so, then there is a chance to really reduce the divergences
by writing much of the sensitive code in this fashion,  If not, then
it is harder to balance the needs of the various VMs vs the obvious goodness
of having as close to a single unified code base as possible.

I personally really don't like having
our own copies of entire classes because it is harder to track changes
in classpath and benefit from bug fixes.  So, there are places where
Jikes RVM is living with very inefficient implementations of library functionality
(almost everything having to do with stack inspection except java.lang.Throwable
which we did reimplement) because in most cases the pain of diverging has
been more important than the performance cost.

--dave

Tom Tromey <address@hidden> 11/07/2003 02:47 PM Please respond to tromey

To:        Andrew Haley <address@hidden>         cc:        David P Grove/Watson/address@hidden, GNU Classpath <address@hidden>         Subject:        Re: VMInterface addition: Make native library names        part        ofVMInterface

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.)

Tom