[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VMInterface addition: Make native library names part ofVMInterface

From: David P Grove
Subject: Re: VMInterface addition: Make native library names part ofVMInterface
Date: Fri, 7 Nov 2003 16:19:15 -0500

I agree.

<disclaimer: I am not a 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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]