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

[Peter Cai]

Oh, you are so nice.

I didn't expected such a comprehensive explanation about GC for my
experience of technique discussion in mailing list.

In the last paragraph,  did you mean that I should reuse buffer or
object as much as possible to get a better performance on MONO?

On 8/2/07, Jonathan Pryor <jonpryor at vt.edu> wrote:
> 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
>
>
>


-- 
Tonight I can write the saddest lines.
To think that I do not have her. To feel that I have lost her.

                              ---- Pablo Neruda