Re: [cp-patches] Patch: RFC: add --with-vm-classes

[Tom Tromey]

Tom> libgcj still has some core classes which diverge from Classpath (and
Tom> which most likely will continue to do so); one example is String.  So,
Tom> I had to add support to the Classpath build infrastructure to let us
Tom> override some core Classpath classes with our own copies.

Mark> How many (and which) other public classes are in the same situation?

Right now there are a lot of classes in this category -- over 100.
However, not all of these represent unsolvable cases.  For instance,
some are related to charset conversion; once the nio changes are
dealt with in libgcj, these can go away.

One important point here is that this approach makes incremental
merging simpler -- once we merge a piece, we simply delete the
override classes from libgcj and then it will not diverge again.

I would say the theoretical minimum number of override classes is on
the order of 10.  At least String (and therefore StringBuffer),
Character, Object, and Class are not likely to be fully merged for the
foreseeable future.

Mark> I am still slightly troubled by the fact that you seem to depend
Mark> on a different class byte code version of some of the public core
Mark> classes. That makes my dream of a common glibj for all tools on the GNU
Mark> platforms further away.

In my opinion doing this makes this dream closer, as it makes it
simpler to do merges and simpler to experiment.  As I see it there are
still unsolved technical problems with making the dream work well for
libgcj.  Namely, first CNI must be made to work BC; second, gcj can't
deal with a non-libgcj Object or Class at the moment, so this would
have to be fixed; and third, someone would have to do a lot of
profiling to show that changing String's representation doesn't hurt.

Mark> The only real nitpick I have with this is that it seems to be an all or
Mark> nothing option. There are not that many classes in vm/reference, 28 atm,
Mark> but it would be nice if the majority could be used as is.

I'm not averse to this if we can make it work.

Originally I planned to make one patch that solved everything, but
while working on it I realized that the result was simply too big to
manage well.  So, my current plan is incremental: do as minimal a
build change as possible, and then, once it is in, write followup
patches to clean up specific oddities.

Tom