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: need to focus on java performance?


Tom Tromey wrote:
Per> One thing worth considering is "whole-package" compilation: a
Per> compilation option to say that there are no other classes in
Per> the package(s) we're currently compiling.  That means that we
Per> know all references to any default-access (package-private)
Per> fields, methods, and classes, which could enable some worthwhile
Per> optimizations.

This idea has come up before.

Unfortunately it isn't clear to me that we can successfully optimize
this and maintain the BC properties needed by the big java programs
out there.  The issue is that all instance fields and methods still
need that extra layer of indirection.

For static fields or methods I don't think you'd need any indirection, since no other code can access them. For instance methods that are have private or package visibility, they'd often be non-overridden, so you can use non-virtual access. The only tricky part is non-static fields or non-static methods that get locally overridden, since where to allocate the fields or methods (in the vtable) may be uncertain. However, if we make an assumption that java.lang.Object is fixed, then any classes that inherit directly from Object or other classes in the same package can also have fixed layout.

Furthermore, if we compile the core java.* classes as a unit,
I think we can certainly optimize away any *internal* indirection.
Client code may need to use indirection, to handle changes in
the library itself (such as adding new private fields), but
the library itself can be compiled to use direct accesses.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


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