Reconsidering gcjx

[Thomas Hallgren]

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
>