On Thu, 2007-08-02 at 08:29 +0800, Peter Cai wrote: > Last week, I've talked with a BEA sales man about their Jrockit JVM. > He told me that any runtime environment would slow done severely when > collecting garbage. And even if Jrockit is the fastest JVM on the > world, it still has that problem.
To a certain extent, that has to be true for *every* system. In C, if you allocate a lot of short-lived objects on the heap, you'll spend a lot of time within malloc(3) and free(3), potentially fragment the heap (depending on allocation pattern), and come to a grinding halt when malloc(3) can't find any free memory because it's too fragmented. (Or on Linux, come to a grinding halt as the system starts paging like mad because malloc(3) never returns NULL.) The answer, as always, is Don't Do That. Lots of short-lived heap-allocated objects isn't good for performance in C. Things are different with a GC, but not terribly: there are some allocation patterns that GC's can deal with efficiently (lots of short-lived objects), and others that are less efficient (e.g. objects which are unreferenced soon after being promoted to Gen2 in .NET, as Gen2 isn't collected very often, so the memory will be occupied-but-useless for quite some time.) So I'm quite sure you could do an XML-RPC server in Java or Mono or anything else, but you'll have to design your algorithms to take your memory allocations into account. Re-using existing memory buffers might be better, or always allocating new buffers might be better; it all depends. Check your GC documentation for more information. (For example, Microsoft blogs have suggested that you profile your app and make sure you spend less than 10% of your CPU time in the GC. .NET has performance monitors to measure the CPU time. If you spend more than that, you'll see noticeable performance problems.) As for Mono, it currently uses the Boehm conservative GC. This means that there is less overhead for collecting garbage -- memory isn't compacted, for example, so you don't have to pay the time cost of a moving collector -- but you also have the heap fragmentation problems of malloc(3) -- you might have enough memory, but you can't allocate an object because there isn't enough contiguous free memory. - Jon _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
