>>>>> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A couple of other factors: Thanks for bringing these up. Per> * Compile time. Yeah, this is a potential problem. If it is severe it could be fixed by linking ecj into GCC. FWIW, at least for all the packaging we do in Fedora, we have to compile things separately, because we're using unmodified upstream build systems. I realize this isn't the only gcj use case. I can try to come up with some timings. Per> * Debugging. Historically Java degugging information is pretty limited. Per> Even with the latest specifications there is (for example) no support Per> for column numbers. However, the classfile format is extensible, and Per> so if needed we can define extra "attribute" sections. Yeah, this could be fixed with some upstream cooperation. Per> * The .classfile format is quite inefficient. For example there is Per> no sharing of "symbols" between classes, so there is a lot of Per> duplication. However, this is a problem we share with everybody Per> else, and it could be solved at the bytecode level, co-operating Per> with other parties, iseally as a Java Specification Request. 1.5 includes Pack200, which addresses this in a somewhat odd way. This seems like a subset of the performance problem though... if performance is ok, this inefficiency won't matter. Per> (2) A bytecode versions of ecj. This is only useful if we also make Per> available a bytecode version of libgcj, I think. Yeah. Right now we have a few java files that we compile based on the target platform, eg the Process stuff. I think we could easily move these around and move to a slightly different approach which would let us have a single libgcj.jar that works for all platforms. For folks not involved in libgcj, the build is essentially done in two steps at the moment. First we compile to class files (this is the classpath part), then we go back and compile to native (using the class files as a kind of precompiled header). In the new setup I think we would compile the class files to object files directly in the second step (since that is what we'd get with ecj anyway). Bringing up libgcj on a new system would involve getting those class files from "somewhere"; with some relatively minor build changes we could just make this a download from gcc.gnu.org. Tom
