cgi-bin

[Erik Poupaert <erik dot poupaert at skynet dot be>]

Hi

I'm trying to work now on an example application in gcj that works according to the
"cgi-bin" system.

That does not only spare me from natively compiling tomcat or similar huge source
piles, but it has the advantage of being conceivably a more *logical* approach, as it
is based on very simplistic unix principles (process forking, executables,
environment variables, stdin, stdout, ...) and installs very easily with the
ever-available apache.

I've already CNI-wrapped String stdlib.getenv() in order to re-gain access to the
environment variables. That works fine.

Now, I've noticed that I've run into a problem: startup time. It's less of a problem
than with bytecode, since libgcj.so is potentially (subsequently) cached in memory.
(What options are there already available to trim its size and therefore load time
and memory footprint?)

A second snag in the startup time is obviously related to all these questionable
classes that are being initialized at startup. Maybe apache will still save me
somehow by engaging in process recycling one way or the other, potentially skipping
re-initialization, but I'd really appreciate a better solution.

If someone patched the gcj sources for a particular gcj option (to be
defined) according to which only the very minimum number of classes (to be defined)
would get initialized, would it stand a chance to be accepted team as a patch?

$ gcj --lightweight ...

According to this option, a truckload of things would be disabled. I was thinking of
decorating some of the sources with:

if(initializing && !System.getProperty("lightweight"))
{
	//heavy weight strand. Bogs down the system to an almost standstill, 
	//but stays compatible with JDK.
...
}
else if(initializing && System.getProperty("lightweight"))
{
	//skip as much as possible. Save performance everywhere.
}