Re: [Sbcl-help] Garbage collection for server with user sessions

[james a. <jam...@se...>]

On 2010-02-27, at 17:04 , Nikodemus Siivola wrote:

> On 27 February 2010 16:46, Brett van de Sande <bv...@as...> wrote:
>
>> If I recompile with a larger value of gencgc-page-bytes, as suggested
>> then gc overall becomes *much* slower.
>
> What about adjusting the max_map_count?
>
>> What about doing a gc that only does generation 5?
>> That is, put a switch in garbage_collect so that, if desired, it only
>> calls  garbage_collect_generation(5,0)
>
> The way the GC works is that you cannot collect generation N+1 unless
> generation N is empty -- so no. This is a fairly fundamental
> assumption in the system.
>
>> OK, I understand that there is no lisp version of free().
>> However, would it help the garbage collection if I applied
>> something like the following to my session data at the close
>> of a session:
>>
>> (defun dereference (obj)
>>       (cond ((consp obj)
>>              (dereference (car obj))
>>              (dereference (cdr obj))
>>              (setf (car obj) nil)
>>              (setf (cdr ojb) nil))
>>        ;; add similar actions for arrays, structs, etc.
>> ))

if you are in a position to do this, you could consider two options  
which are (+/-) variations of the "db" option nikodemus mentioned:
- resource (especially large) objects. that is, institute a protocol  
for them which is the equivalent of allocate&free.
- intern reappearing, but otherwise unique objects. that is, replace  
references with those to an "equal" object which will never be gc'd.

that is, even though you have already reduced the unique data per  
session to just 1MB, you may be able to reduce the data subject to gc  
a yet smaller subset of that.

>
> To a degree, yes.
>
> Doing it always for everything is almost certainly a bad idea, but
> doing things like CLRHASH for hash-tables or FILL for vectors can be
> worthwhile.
>
> It all depends: if cleaning out pointers means you're writing to
> write-protected pages it is going to be a loss -- but if those pages
> are dirty already, it is probably a win.
>
> Cheers,
>
>  -- Nikodemus
>
> ---------------------------------------------------------------------- 
> --------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help