This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]