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

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

On 2010-03-18, at 01:40 , Brett van de Sande wrote:

>>>
>>> Thanks.  That (hash consing) is essentially what I am doing.
>>> The only twist is that I am saving the the lisp expressions to a
>>> file (along with a table of pointers) and, when I am running my
>>> server, I reconstruct the cons pointers as I read the expressions
>>> from the file.
>>
>> you are not describing everything.
>>
>> when is "when i am running my server"? when it starts up, or on each
>> request?
>>
>> in any case, your problem does not sound like one where hash consing
>> will be the complete answer.
>> from what you have revealed so far, you do not want to release the
>> resources.
>>
> Sorry for the vagueness.  What I do is the following:  I generate
> model solutions to the problems in Andes beforehand and save them
> in data files.  These model solutions are represented mainly in terms
> of lisp expressions.
>
> When I am running my Andes server and a student starts solving a  
> problem,
> I read in the model solutions from the appropriate data file.
> In this case, I need the model solutions to be stored efficiently in
> memory, since there will be several hundred students working  
> simultaneously on
> different problems.  Once the student is finished working on that  
> problem,
> I no longer need that model solution and the data is freed for garbage
> collection.
>
> Obviously, if several students are working on the same problem,
> I could share some of the data, but I need to support the case
> where all students are working on different problems.

what you have so far revealed implies that

- you have persistent models which you manipulate and present
   in response to requests.
- these models combine some persistent/static data and some
   dynamic/per-session data.
- the complete set of models takes more space than the heap would allow.
- the models for any given actual simultaneous session mix do fit in  
heap.
- you load model state from external storage on demand.
- you free models when no longer used - through gc possibly combined
   with weak sets and/or releasing.

given this situation, you experience memory exhaustion despite that  
no session ever requests more than its unit resources.

? what happens if you arrange the request mix such that the models  
are never released. that is, there is always some session which uses  
each model and the session mix is limited such that no more than the  
maximum expected permitted number of models is required. does this  
eventually exhaust memory as well or does it survive?

if such a configuration survives, then one option is for you to  
arrange to never release the static model memory. instead, you  
recycle it.
when a model must be loaded, you reuse the storage from a previous,  
no longer in use model. if there is none available, then the request  
must wait. if you can keep the per-session data small enough that it  
is never promoted, then you never require more than ephemeral gc.

if the entire model is s-expressions and function objects, reuse  
would be difficult as the former are very fine-grained and the latter  
are difficult to recycle. one would need more information about the  
model. if there are higher-level composite data structures, the  
approach offers advantages.