Reconsidering gcjx

Fri Jan 27 12:38:00 GMT 2006

Hear, hear!
I think using ecj as a gcj front end sounds like a terrific idea!
Kind regards,
Thomas Hallgren
Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss them below.
>> Steering committee members, please read through if you would. I think
> this requires some resolution at the SC/FSF level.
>> First, a brief note on gcjx. I had intended gcjx to serve not only as
> a cleanly written replacement for the current gcj, but also as a model
> for how GCC front ends should be written in the future; in particular
> I think writing it as a library and separating out the tree-generating
> code from the bulk of the compiler remain good ideas. I enjoyed, and
> continue to enjoy, the writing of gcjx. However, in this case I think
> that pleasure must give way to the greater needs of efficiency and
> cross-community cooperation.
>>> Motivation.
>> The motivation for this investigation is simple: sharing code is
> preferable to working in isolation. In particular this change would
> let us offload much of the front end maintenance onto a different
> group.
>> Ecj has a good front end (much better than the current gcj) and decent
> bytecode generation. It is fully 1.5-compliant and, apparently, is
> tested against the TCK by the upstream maintainers (us gcj developers
> don't have TCK access). It also has some improvements for 1.6 (stack
> maps). Upstream is very active.
>> gcjx by comparison is unfinished and really has just a single
> full-time developer, me.
>>> Technical approach.
>> Historically we've wanted to have a 'native' java-source-code-reading
> compiler, that is, one which parses java sources and converts them
> directly to trees. From what I can remember this was based on 3
> things:
>> * In the past the compiler handled loops built with LOOP_EXPR better
> than it handled loops built "by hand" out of GOTO_EXPRs. My
> understanding is that this has changed since tree-ssa. The issue
> here was that we made no attempt to rebuild a LOOP_EXPR from java
> bytecode.
>> * The .java front end could do a "constant array" optimization. This
> optimization has not worked for quite some time (there's a PR). In
> any case we could implement this for bytecode if it matters.
>> * The .java front end could more efficiently handle class literals.
> With the new 1.5 'ldc' bytecode extension, this is no longer a
> problem.
>> In other words, as far as I can remember, our old reasons for wanting
> this are obsolete.
>> I think our technical approach should be to have ecj emit class files,
> which would then be compiled by jc1. In particular I think we could
> change ecj to emit a single .jar file. This has a few benefits: it
> would give -save-temps meaning for gcj, it would let us more easily
> drop ecj into the existing specs mechanism, and it would require very
> few changes to the upstream compiler.
>> An alternative approach would be to directly link ecj to the gcc back
> end. However, this looks like significantly more work, requiring much
> more hacking on the internals of the upstream compiler. I suspect
> that this won't be worth the effort.
>> In my preferred approach we would simply delete a portion of the
> existing gcj and turn jc1 into a purely bytecode-based compiler. Then
> we would proceed to augment it with all the bits needed for proper 1.5
> support.
>> ecj is written in java. This will complicate the bootstrap process.
> However, the situation will not be quite as severe as the Ada
> situation, in that it ought to be possible to bootstrap gcj using any
> java runtime, including mini ones such as JamVM -- at least, assuming
> that the suggested implementation route is taken.
>>> Politics.
>> I don't know whether the FSF or the GCC SC would let us import ecj,
> even assuming it is actually GPL compatible. SC members, please
> discuss.
>> We don't know how upstream would react. I think this is a fairly
> minor risk.
>> It is unclear to me whether we must even rely on GPL v3 if we went
> with the separate-ecj route. Any comments here? In the
> exec-via-specs approach we're invoking ecj as a separate executable,
> much the same way we exec 'as' or 'ld'. Comments on this from
> license-oriented folks would be appreciated.
>>> Summary.
>> I think this would be the most efficient way to achieve 1.5 language
> compatibility for gcj, and it would also make future language changes
> less expensive. Given the scope of the entire gcj project, especially
> when the scarcity of resource devoted to it are taken into account,
> this is significant enough to warrant the change.
>> Tom
>