Hi,
On Wed, 2005-07-06 at 16:40 +0100, Gary Benson wrote:
> Over the past couple of days I've been writing a replacement for
> aot-compile and find-and-aot-compile. They were both good when they
> were first written but the demands of Eclipse and JOnAS have exposed
> numerous shortcomings.
>
> Attached is a copy of aot-compile-rpm which I'd like to commit into
> java-1.4.2-gcj-compat if everyone's agreeable. It's an order of
> magnitude more complex than aot-compile and find-and-aot-compile, but
> it's advantages over them are manifold:
>
> IT'S MUCH MORE USABLE
> =====================
> Nativifying an rpm using aot-compile-rpm is a matter of
> copy-and-paste:
>
> 1. Remove "BuildArch: noarch"
> 2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp"
> and "Requires(post,postun)" on same.
Releng told me to separate these requires:
Requires(post):
and
Requires(postun):
because certain versions of RPM fail on the (post,postun) syntax.
> 3. Add "aot-compile-rpm" to the very end of %install.
> 4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun.
> 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
>
> With aot-compile or find-and-aot-compile step 4 was much more
> complex. I was always uneasy about nativifying things I didn't
> myself maintain, postgresql-jdbc for example, because I was wary of
> dropping a bunch of fragile code on someone else. No longer.
>
> IT FINDS JARS BY SIGNATURE RATHER THAN BY EXTENSION
> ===================================================
> find-and-aot-compile identifies jarfiles by their extension, ".jar",
> so it misses ".war", ".ear", ".rar", and anything else the Java
> world happens to invent. aot-compile-rpm identifies jarfiles by
> opening them, so it catches them no matter what they're called.
>
> It's already found some unexpected stuff. Tomcat, for example, has
> a couple of servlets that are disabled by default because they are
> in jarfiles called ".renametojar". aot-compile-rpm finds and
> compiles these, so if the user renames them to enable the servlets
> then they'll be running BC-compiled code.
Does aot-compile-rpm provide a way to exclude certain jars from native
compilation? This is sometimes necessary to work around gcj bugs.
>
> IT IGNORES SUBSETTED JARFILES
> =============================
> Several packages contain jarfiles which are a subset of others.
> MX4J, for example, has the APIs in mx4j-jmx.jar, the implementation
> in mx4j-impl.jar, and both together in mx4j.jar. aot-compile-rpm
> recognises that compiling mx4j.jar will get every class in the other
> two jars too, so it'll only compile mx4j.jar. So, aot-compile-rpm
> compiles MX4J in half the time (and generates half the bytes) that
> find-and-aot-compile does.
>
> IT WORKS AROUND THE PPC GO2 LIMIT
> =================================
> PPC machines are limited on the size of jarfiles that can be
> compiled in one go, affecting Eclipse and JacORB, as described
> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
> aot-compile-rpm splits large jarfiles on ppc to avoid this.
>
> One limitation of aot-compile and find-and-aot-compile that I have not
> addressed (yet) is SMP support. Andrew Overholt suggested generating
> a Makefile and letting make handle the complex stuff, which I think is
> an excellent idea. Implementing something along those lines is
> something I'd like to do, but I need to get ppc64 and s390*
> bootstrapped first.
Great! This will be excellent.
Tom
