ARM support

Thu Jul 3 09:20:00 GMT 2003

> This can be done at link time if a linker is sufficiently smart.
> Indeed, it is done for C++, where it is called "vtable garbage
> collection." 

Modifying gcj to emit the proper markers, and modifying ld to utilize them, sounds
like a major development effort, involving the risk of subtly affecting existing
tools, that actually work fine already. It also requires the profound knowledge of
deeply buried internal APIs inside the toolchain.
In the meanwhile other people are changing other things, and before you know, you've
accidentally broken someone's special stuff that used to work properly on the one or
the other obscure platform supported by GCC since 1987 :-)
That's why I was thinking along the lines of favouring the re-use of the toolchain 
up to the point where a fully validated abstract syntax tree is available for
emitting backend instructions. Instead of emitting assembler, this new effort could
emit java again, but then purged. The purged source would then simply be re-injected
into the toolchain, which wouldn't even need to know about it.
The question remains if the frontend parts in gcj that produce fully validated
abstract syntax trees have documented APIs that can be invoked safely in such re-use
strategy. In my impression, less knowledge would be required; and fewer internal APIs
would need to participate to pull it off.
I would need something like (native or Java, doesn't matter):
try
{
	AST ast=GcjFrontEnd.parse(thisJavaFile);
}
catch(ParserException e)
{
	System.out.println("the file " + thisJavaFile + " is invalid.");
}
The ability to obtain a fully validated ast for a source file is tremendously
valuable. You can re-use it in so many different contexts. I was thinking of
source code completion in editors, documentation tools, and so on. However, it should
use the same lexer, parser, and validators as the real compiler uses.
> The problem in Java is that every method is reachable by
> reflection.

That problem occurs already when linking statically while calling with reflection
into classes that are not otherwise referenced explicitly. We wouldn't
be introducing any new problems.