This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Tuomas Leikola <tuomas dot leikola at digia dot com>
- Cc: java at gcc dot gnu dot org
- Date: Tue, 29 Jan 2002 13:41:23 +1300
- Subject: Re: about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)
- References: <05d201c1a7e4$f99afa30$3a090a0a@tobo>
Tuomas Leikola wrote:
>>Huh? Are you suggesting you want to statically link your small
>>command-line-tools?
>>
>
>umm.. if they become small enough or i'm using some c64 or something that
>doesn't support shared libraries? ;)
>
Fair point. Obviously being static is important for some embedded devices.
>agreed. but then again, closed world means just that.
>
>is libgcj so stable that you can just depend on it and not worry about the
>next week? i've seen the ms DLL hell, would consider static linking a ..
>compatible solution in the long run :(
>
Not yet. But that is certainly a goal. One day I hope that libgcj will
be common (and stable) as glibc, so you can distribute your small
dynamically linked command line java utilities (or your huge java gui
app) with no worries.
That means that your binaries automatically gain the benefits of
bugfixes and improvements when you upgrade your libgcj. And it means
that all the code in libgcj.so gets shared automatically in memory
between different applications.
>yes, it's tricky to do in code, simpler to do by hand. i suppose gcj already
>does multiple passes on different optimization techniques until no-one of
>then can suggest a change?
>
We don't yet do much in the way of Java-specific optimizations. We are
really waiting for the ast-level optimization framework to develop
before we can look at this. However by inlining things like the simpler
type checks the generic optimizer will be able to work better. eg:
if (foo instanceof Bar)
bar = (Bar) foo;
Currently gcj will make libgcj calls for both the instanceof and the
cast. But by inlining them the generic CSE pass will be able to tell
that the second check is redundant and remove it completely.
>my point tried to be resolving interface calls statically, but it seems it's
>not as slow as i thought (according to shudo's benchmarks)
>
Yes, we have a pretty good interface dispatch scheme. The interface
lookup still requires a runtime call, but will be made faster by inlining.
regards
Bryce.