[BC ABI] gcj-abi-2-dev-branch created
Vladimir Levin
vladimirl@wrx-ca.com
Fri Apr 16 15:23:00 GMT 2004
I am not familiar with this thread. Will the new ABI and related work
make it harder to use GCJ for embedded development? In particular, on
our board, we cannot put the entire libgcj.so on the flash. So far,
using gcc-3.2.3 the static executable size is about 2 MB (for hello
world)... But a base size larger than that becomes unacceptable...
Andrew Haley wrote:
>This branch is for work on the new ABI.
>>For those who haven't seen the discussions, the idea of the new ABI is
>to conform fully to the Java Binary Compatibility specification, which
>is Chapter 13 of the Java Language Specification.
>>Now classes are looked up at runtime rather than compile time, so the
>runtime of libgcj has to be completely reorganized.
>>Some of this work is already done: the compiler changes so that we no
>longer emit hard references to classes are already done, and some of
>the runtime is done but it's very Alpha at the present time. There's
>a ton of debugging code in there, too.
>>Much remains to be done. Some of the important missing things are:
>>* The compiler must output assertions so that at runtime incompatible
> class changes are detected. At the moment it just emits warnings to
> the console.
>>* In resolve.cc, we need to look for precompiled classes and if they
> are not found launch gcj to compile them to shared objects.
>>* The compiler should no longer open class files referred to when
> compiling class files. Instead, where any type checking is needed,
> it should embed type check assertions in the generated object file.
>>* The bytecode verifier in the compiler needs to be fixed in order to
> verify some of the weirder bytecode out there.
>>* We need to control the export of symbols from libraries.
>>* We need to fix mangling so we can use generics.
>>* The runtime class resolution is insanely complicated, messy, and
> probably totally wrong. It doesn't correctly lock tables.
>>* gdb will not work well with this ABI.
>>* We need to rip out -fno-assume-compiled support.
>>To summarize: the completion of this work will greatly lower the bar
>for people who want to use gcj. They'll only have to precompile their
>jarfiles, and everything else should Just Work. This will increase
>the takeup of gcj. I hope... :-)
>>Rules for working on the branch:
>>* Talk about what you're going to do on this list before starting.
> This is to reduce wasted effort.
>>* By all means commit debugging stuff, and stuff that still has
> FIXMEs. Don't forget to mark stuff you're not sure about.
>>* Post patches for approval as usual on java-patches, marked [BC ABI].
>>Andrew.
>>
More information about the Java
mailing list