Gary Benson wrote: > Costin Manolache wrote: >> My benchmarks ( > 1 yr ago ) showed GCJ-based tomcat to be as fast >> as the IBM JDK1.3 ( the fastest VM at that time ). There were small >> differences under different loads - but the garbage collector seemed >> like the biggest factor ( GCJ performed worse on JSP pages where >> more objects were created if I remember correctly ). > > Do you still have the benchmark code around? I'd love to see it...
No special code - I used the same tests as for regular tomcat. The tricky part was getting tomcat ( and all its depedents ) compiled with GCJ, then figure out how to deal with resources. Dynamic class loading turned out to just work, but I think I had to do few tweaks in the class loader ( basically hack it to use a flat loader - probably now it won't be needed ). After tomcat was working - "ab" with servlets and jsps. >> The amazing thing was the startup time - almost 0 ( it felt more >> like apache :-). > > It does start up fast :) The compiler we're using has a funky > experimental optimiser (the same as used in the fast free eclipse > project), and the startup became perhaps twice as fast when I switched > from gcj 3.3. It compiles JSPs pretty fast too. That's one reason > why I'd like to benchmark it. Startup time is probably more important for ant or javac or other things that are run frequently. But it is cool to see tomcat start in the same time as apache. ( or ant as fast as make ) > >> BTW - GCJ is not a virtual machine and doesn't have a JIT - it is a >> ahead-of-time compiler, just like C and C++ compilers. > > This may have been true a while back, but it isn't now -- gcj can > interpret bytecode just like any other JVM. In my Tomcat package this > is exactly what it does when executing servlets (everything else is > built to native code). You're right in that doesn't have a JIT > though. I did compile the servlets as well to native. >> The biggest problem at that time was dynamic class loading. GCJ has >> a small interpretor and could load servlets - but the difference in >> performance between precompiled code and interpretor was >> significant. > > It probably still is, though not as bad. But it's not such a big > problem as it seems, as most of the calls that a given servlet makes > will be to native-compiled methods. JSPs tend to have a lot of code inside. The interesting part is that class loading works ( or it used to work ) by using .so files. So it should be possible to hack the webapp deployer to invoke gcj on all the jar files in lib/ and generate the .so. I don't know how easy it is to get the .so files loaded, but I'm sure gcj uses dl* to work with the .so files. The only major problem I see is the sandbox - but unfortunately most people don't use it anyway ( even if they should ). From a security point of view - compiling all the servlets to native or running in JDK without sandbox is equivalent - a bad serlvet can do as much damage as it wants. But if you want security - I'm not sure if GCJ implements the sandbox and all the code verifications that are needed - last time I looked it didn't seem to. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
