This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reconsidering gcjx


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:

A couple of other factors:


* Compile time.  It is at least potentially faster to compile directly
  to trees.  However, this is negated in many cases since you want to
  generate both bytecoe and native code.  (This include libgcj.)
  So generating bytecode first and then generating native code from
  the bytecode is actually faster.

* Debugging.  Historically Java degugging information is pretty limited.
  Even with the latest specifications there is (for example) no support
  for column numbers.  However, the classfile format is extensible, and
  so if needed we can define extra "attribute" sections.

* The .classfile format is quite inefficient.  For example there is
  no sharing of "symbols" between classes, so there is a lot of
  duplication.  However, this is a problem we share with everybody
  else, and it could be solved at the bytecode level, co-operating
  with other parties, iseally as a Java Specification Request.

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.

I think you're right. It could be a project for somebody to tackle later.

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.

I don't a "mini java runtime" would be useful. We could offer two bootstrap solution: (1) An existing (installed) Java run-time, which would be an older version of gcj. (2) A bytecode versions of ecj. This is only useful if we also make available a bytecode version of libgcj, I think. -- --Per Bothner per@bothner.com http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]