section-gc and gcj

[Adam Megacz]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> >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?

No, I didn't -- I was just had the linker ignore unresolvable
relocations.


> 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.

Yes, I agree that this is a better long-term solution, although I
would like some automation in terms of figuring out which methods are
needed. I don't want to go through libjava, method-by-method, picking
out what I need.

My experiment was just an attempt at getting some quick hack to work;
sadly, it failed =) Right now I'm looking for a solution that's going
to work in a timetable of a few days. That's probably not going to
happen unless I can figure out how to get i686-pc-mingw-ld to do
section-gc in a hurry (it doesn't right now). Otherwise people have to
put up with a 1.5MB (compressed) download, which is pretty huge.



> That said, I mostly dislike the idea of static binaries for desktop 
> application.

Yeah. Keep in mind I'm writing ActiveX controls and Navigator/Mozilla
plugins, though. I can't count on libjava.dll/so being on the client
end, and sending the the entire libjava isn't feasible from a
download-time standpoint -- I just want to send what I absolutely
need.

So, in summary, I'm in a strange situation that most other people
aren't likely to wind up in (download size matters a lot). Whatever
the long-term solution is, it doesn't really need to take my situation
into account.

I'd love to see libjava.so become standard-issue on Linux distros,
though... Debian already has a package just for libgcj (seperate from
gcj).



> 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.

Wow, I didn't know that.

Why did the designers choose to implement these things differently
instead of simply transforming Java code into a C++-compatible
abstract syntax tree? That would make CNI "just work" as a side
effect.

  - a