Re: Time to heat up the new module discussion

[Miguel de Icaza <miguel ximian com>]

Hello,

> > Am not quite sure what you mean by "the build system of Mono", there is
> > no such thing as "the build system of mono".   Maybe you mean that you
> > need to have the "mono" command installed?
> 
> That + all the assemblies.

Ok, so the runtime libraries. 

These are in no way different to any of our libraries that includes more
than the shared library: they include pixmaps, data files, glade files,
configuration files, schemas and so on.

> Contrast with GCJ which links in only whats needed to create a compact 
> native stand alone executable - that is what AOT should be IMO. (is the 
> SoC project to create a linker basically this?)

No, the SoC code is for a different purpose.  Its used for people that
might want to embed Mono into a smaller space, or want to create
smaller/larger libraries by linking one or more assemblies into one (for
instance, the "Compact" profile of Mono will be created by passing a
list of classes and methods to the linker).

> so in other words it will spike every now and again EG if under Boehm GC 
> I have 50MB heap then in compacting mode its going to spike from 50 to 
> 100+ MB (how much higher depends on the no. of generations you have and 
> how incremental it is of course)

Yes, but the spike is not 2x the memory you have allocated.  The spike
is the size of the nursery (512k).

> Im not sure how this helps mono though except maybe you can claim it 
> will be faster.

A compacting collector helps long running applications by returning
unused memory to the OS.  Memory that typically would be trapped in
unusable gaps.  These unusable gaps are hard to predict, and they depend
on the allocation pattern of each application.

Miguel