> OK, I think this approach might lead you into trouble, and explain the
> slow times and (if I remember) large image sizes you were reporting.
What's the size of saved_ansi_gcl on Debian for instance ?
> There are bacially two memory paradigms in GCL, garbage collection
> (GBC) and malloc/free. The arguments in favor of one or the other
> have been tossed about for years. In any case, it is expected of lisp
> systems to have automatic GBC memory management.
> But GCL can use some third party libraries, like gmp, which in turn
> use malloc/free. So it simulates these calls *on top of* the GBC
> mechanism by making a malloc list, and entering a 'mark origin' for
> this list. All such memory blocks will be typed as 'contiguous'
> pages, one of the ~ 30 types GCL currently supports. All such blocks
> will also be completely marked at GBC time until explicitly freed.
> Therefore, if your alloc_object (i.e. non-third party library lisp
> object allocation) goes through malloc, these pages will never be
> freed, and the garbage will never be collected. => big and slow, and
> possible memory exhaustion.
My apologies, I think I didn't get myself clear enough. The memory
management scheme I have is really the same as what you've just described
here with these third party calls implemented on top of the GBC mechanism.
I have NOT touched alloc_object. What I meant was that the storage for
such third party calls is backed by the big vm area allocated upon
initialization, since the storage for the GBC mechanism is backed by the
same big vm area.
Can I infer from what you say that contiguous pages will never be subject
to page protection changes ?
> SGC is an optional performance feature as you state. The idea is that
> some systems have large *static* data sets, and the system just wastes
> time passing these pages through GBC. So mark these pages read only,
> GBC a much smaller frequently changing set of pages, and when the odd
> write happens to the static page, mark it read write and schedule it
> for GBC marking too.