[Mono-list] Is mono suitable for building an XML-RPC Sever?

[Jonathan Pryor]

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