[Ecls-list] Strange error

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> On Sat, May 31, 2008 at 3:54 AM, Waldek Hebisch
> <hebisch at math.uni.wroc.pl> wrote:
> > I must admit that I was somewat surprised to see how large
> > process size may get -- I am loading a lot of fasls (1090 in
> > final stage), but on disk they take about 70 Mb.
> 
> I suspect that this is related to the problems I experienced by
> removing the garbage collection phase from cl_load(). There is a weird
> interaction between the garbage collector and the dynamic linker going
> on. Or maybe the gabage collector is not aggressive enough when using
> the incremental algorithm.
>

I am surprised by large process size, but I am not worried.
Namely, given that no swap is used used memory is the same as
resident set size, and this is rather low, IIRC below 100 Mb at
peak time and typically much smaller amount.  In Linux process size
is "purely virtual" memory, there is no need to have real memory
(or even swap) to support it.  For example openmcl at startup
allocates 512 Gb (IIUC this allocation is supposed to reserve
address space, to avoid any problem due to address space fragmentation).
so process size is huge, but it uses only needed amount.

It is possible that Boehm-Wiser gc plays similar to openmcl tricks
to reserve address space without actually using memory.
  
> > Another thing is why I am getting segfault -- I would expect ECL
> > to detect failing allocation and react more gracefully.
> 
> The problem is that the garbage collector is using this signal itself
> to detect dirty pages. We cannot trap those signals if you use
> --enable-gengc.
> 

Well, the message says that null is return.  I simply expected ECL
to follow old-fashioned approach of checking return value from
GC_malloc...

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl