section-gc and gcj

Fri Jan 4 21:03:00 GMT 2002

Adam Megacz wrote:
>Hrm, so I tried to build a vtable gc postprocessor that would take
>both a .jar and a pile of .o's, use the .jar (and included .class
>files) to figure out which methods were "reachable", and then remove
>all unreachables (by stripping their symbols) from the .o, and wrap it
>up in to a .a. It works (mostly), and it's a great hack until we have
>vtable gc.
>
Interesting. Did you end up using --indirect-dispatch to get rid of 
static references to virtual methods in vtables? As I've said before, I 
think the best solution here is to weaken the linking model sufficiently 
so that the compiler/user can make the decisions about what gets 
included in a static binary without worrying about linker errors 
(instead they would be runtime exceptions). This is more portable and 
powerful (although more work) than supporting it though GC.
That said, I mostly dislike the idea of static binaries for desktop 
application. I'm much more interested in working towards binary 
compatibility stability for libgcj.so/libgcj.dll and making sure they 
are easily distributed/installed. Some of the reasons why a shared 
library is better:
- code shared between applications / less memory usage
- can fix bugs and improve underlying runtime without recompiling 
application
- smaller application binaries
- better suited to Java's dynamically extensible nature. Not having a 
complete set of runtime classes available basically prohibits the 
dynamic loading of extension/plugin code because you have no way of 
knowing what classes they will require.
> AFAIK, gcj
> just transforms a Java source file into a C++ abstract syntax tree,
> then throws it over the fence to the C++ backend, which is why CNI
> works so well (you're just skipping over the Java-to-C++
> transform). 
>This description is not entirely accurate. It is more correct to say 
that gcj transforms a Java source file into a GCC abstract syntax tree. 
This abstract syntax is language independent, although front-ends do 
define their own custom tree nodes to represent higher-level concepts. 
CNI really works only by convention: the Java and C++ front ends 
(unfortunatly) do not share a common representation of concepts like 
namespaces/packages and virtual method tables.
regards
Bryce.