Idea: profiling gcj vrs jvm memory use on linux

So, gcj is supposedly a compiler which compiles java code to standard elf format libraries and executables.  How does this effect memory use in java code?  Specifically, each instance of a jvm would normally load local copies all it's java libraries, right?  And since standard java libraries are just other jars and/or class files, they wouldn't be shared.   So multiple jvm instances would load multiple copies of the java libs, one per each jvm.

But, since gcj could compile libraries to standard linux style shared libries, aka .so's, this might be different.  Remember that .so's are only loaded into memory once, no matter how many processes libk these into their local address space.

Ergo, if I'm correct about this, there could be a significant memory savings for gcj compiled libraries vrs. standard jvm instances where there are many instances running.  This means there may be effects on total memory use, on the amount of i/o to start processes, on the amount of i/o for paging and swapping, and possibly on memory cache locality.

This could have impact for things like hpc (yeah I know, hpc in java?  I've seen it, though ...), or maybe even allow something interesting like a web / app service portal where different EAR's or WAR's are loaded as different linux processes. 

I'll see if I can do something around this in the next couple of months.

BTW -- I don't know offhand how practical this would be, but I rather like the idea of isolating different EAR's / WAR's into different linux processes.  Right now it's annoying to look at a trashing JBOSS instance, say, and isolate performance effects to a particular EAR.  It'd be notably easier to do this if each EAR was a different process.  Comments on the practicality of this?

-- Pat